On Monday, August 2, 2021 at 2:13:38 PM UTC-7, ******@aol.com wrote:
> I don't know what the sequencing logic overhead would be (probably too much), but consider:
> Get rid of the direct page.
> Make the SP 16 bits.
> Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.
> I'm not real familar with the 6502 ISA, but I think you should be able to do something
> like: LDA [SP+offset],X
> which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
> Since all this is on the stack, instantly gets rid off all the DP allocation contention.
> It is also MUCH friendlier to generated code from compilers.
> The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...
>
> (I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).
>
> - Tim

The 65c816 added a 16-bit S, and (d8,S),Y and d8,S addressing modes that could be quite useful, but it also added a bunch of other stuff that never really flipped my switch.

Timothy McCaffrey <timcaffrey@aol.com> schrieb:

> I don't know what the sequencing logic overhead would be (probably too much), but consider:
> Get rid of the direct page.

Agreed.

> Make the SP 16 bits.

I would probably try to limit the special registers as far as
possible, to save transistors. Having a stack pointer (other
than just using that as a convention for a regular register)
would entail something like an auto-increment.

> Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.

What is a DP?

> I'm not real familar with the 6502 ISA, but I think you should be able to do something
> like: LDA [SP+offset],X
> which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
> Since all this is on the stack, instantly gets rid off all the DP allocation contention.
> It is also MUCH friendlier to generated code from compilers.

That was certainly not a concern at the time :-)

> The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...
>
> (I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).

Memory-mapped IO? Not sure what you mean here.

On Tuesday, August 3, 2021 at 12:14:02 PM UTC-4, Thomas Koenig wrote:
> Timothy McCaffrey <timca...@aol.com> schrieb:
> > I don't know what the sequencing logic overhead would be (probably too much), but consider:
> > Get rid of the direct page.
> Agreed.
> > Make the SP 16 bits.
> I would probably try to limit the special registers as far as
> possible, to save transistors. Having a stack pointer (other
> than just using that as a convention for a regular register)
> would entail something like an auto-increment.
Well, the 6502 already had a stack pointer, it was just 8 bits.

> > Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.
> What is a DP?
Direct Page, or the first 256 bytes.
> > I'm not real familar with the 6502 ISA, but I think you should be able to do something
> > like: LDA [SP+offset],X
> > which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
> > Since all this is on the stack, instantly gets rid off all the DP allocation contention.
> > It is also MUCH friendlier to generated code from compilers.
> That was certainly not a concern at the time :-)

Yes, it wasn't. Part of the trick of building a better CPU with modern knowledge is knowing that
such a thing *should* have been a concern.

> > The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...
> >
> > (I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).
> Memory-mapped IO? Not sure what you mean here.
The 6800, 6502, & 68000 all used memory mapped I/O (a portion of the memory space was carved out by external logic so
it generated I/O selects instead of memory). The 8080, et al, used a dedicated signal (and instructions) to indicate I/O read/writes.
Boards using the 6800 & 6502 typically used at least part of the DP for I/O ports. This was especially true for SOCs.
For an embedded board it made sense as it could help reduce program space it a tightly constrained memory.

- Tim

timca...@aol.com wrote:
> On Tuesday, August 3, 2021 at 12:14:02 PM UTC-4, Thomas Koenig wrote:
> > Timothy McCaffrey <timca...@aol.com> schrieb:
> > > I don't know what the sequencing logic overhead would be (probably too much), but consider:
> > > Get rid of the direct page.
> > Agreed.
But 16-bit direct page allows for easy frame creation (also in high level languages), allowing for efficient reentrant code.

> > > Make the SP 16 bits.
> > I would probably try to limit the special registers as far as
> > possible, to save transistors. Having a stack pointer (other
> > than just using that as a convention for a regular register)
> > would entail something like an auto-increment.
> Well, the 6502 already had a stack pointer, it was just 8 bits.
> > > Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.
> > What is a DP?
> Direct Page, or the first 256 bytes.
> > > I'm not real familar with the 6502 ISA, but I think you should be able to do something
> > > like: LDA [SP+offset],X
> > > which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
> > > Since all this is on the stack, instantly gets rid off all the DP allocation contention.
> > > It is also MUCH friendlier to generated code from compilers.

> > That was certainly not a concern at the time :-)
> Yes, it wasn't. Part of the trick of building a better CPU with modern knowledge is knowing that
> such a thing *should* have been a concern.
Not really. There were very well designed industrial ISA's like IBM/360 for "advanced IT", but we are talking about simple $25 microprocessor that was accidentally promoted to CPU role.
Compilers where inefficient, memory was expensive, so everything serious was written in assembler.
High level languages required 16 bit arithmetic, the common way was to write virtual machine (like SWEET16). Virtual machines offered much more expressive and compact assembler for the price of 10x slowdown.
The simplest way to improve 6502 in the context of high level languages is to make all registers and operations 16 bit, sacrificing 8 bit performance. This should allow to obtain code density comparable to VMs.
We should add new 16bit direct page, with optional optimization: pages having lower byte equal zero should change addition into concatenation during address generation (optimisation can be triggered by instruction).
BCD arithmetic should be replaced by instructions for data conversion.
The final result is a simplified 65816, using 16-bit addresses, 8-bit ALU and without 8-bit modes hell.

> > > The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...
> > >
> > > (I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).
> > Memory-mapped IO? Not sure what you mean here.
> The 6800, 6502, & 68000 all used memory mapped I/O (a portion of the memory space was carved out by external logic so
> it generated I/O selects instead of memory). The 8080, et al, used a dedicated signal (and instructions) to indicate I/O read/writes.
> Boards using the 6800 & 6502 typically used at least part of the DP for I/O ports. This was especially true for SOCs.
> For an embedded board it made sense as it could help reduce program space it a tightly constrained memory.
>
> - Tim

On 08/03/21 21:39, Timothy McCaffrey wrote:
> On Tuesday, August 3, 2021 at 12:14:02 PM UTC-4, Thomas Koenig wrote:
>> Timothy McCaffrey<timca...@aol.com> schrieb:
>>> I don't know what the sequencing logic overhead would be (probably too much), but consider:
>>> Get rid of the direct page.
>> Agreed.
>>> Make the SP 16 bits.
>> I would probably try to limit the special registers as far as
>> possible, to save transistors. Having a stack pointer (other
>> than just using that as a convention for a regular register)
>> would entail something like an auto-increment.
> Well, the 6502 already had a stack pointer, it was just 8 bits.
>
>>> Instead of the DP, change most DP addressing to be SP+(unsigned) offsets.
>> What is a DP?
> Direct Page, or the first 256 bytes.
>>> I'm not real familar with the 6502 ISA, but I think you should be able to do something
>>> like: LDA [SP+offset],X
>>> which adds offset to SP, loads the 16 bit address, adds X to it and loads A from the resulting address.
>>> Since all this is on the stack, instantly gets rid off all the DP allocation contention.
>>> It is also MUCH friendlier to generated code from compilers.
>> That was certainly not a concern at the time :-)
>
> Yes, it wasn't. Part of the trick of building a better CPU with modern knowledge is knowing that
> such a thing *should* have been a concern.
>
>>> The stack based values end up acting like registers, and if you want to make things faster, start caching the stack...
>>>
>>> (I know, everyone liked to put MMIO devices in the DP. Great for the embedded market, not so much for general computing).
>> Memory-mapped IO? Not sure what you mean here.
> The 6800, 6502,& 68000 all used memory mapped I/O (a portion of the memory space was carved out by external logic so
> it generated I/O selects instead of memory). The 8080, et al, used a dedicated signal (and instructions) to indicate I/O read/writes.
> Boards using the 6800& 6502 typically used at least part of the DP for I/O ports. This was especially true for SOCs.
> For an embedded board it made sense as it could help reduce program space it a tightly constrained memory.
>
> - Tim

One trick to minimise address decode logic, at least
for the systems here, was to use the top address bit to
split code and io space at the top, with ram memory at
the bottom. Then, another simple decode with the next
address bit down to select either io device or code
space.

A lot of talk about a better 6502, but having spent
a couple of years programming asm for 6502 based
embedded systems, the architecture had more than enough
capability for the task. The indirect addressing modes
in particular, provided a sort of virtualised 16 bit
operation capability. Never had any issues with
page zero usage, or running out of space. We built
complex systems using 6502, some of which are
probably still in use.

All in all, brilliant piece of design work for it's
time...

Chris

On Tuesday, August 3, 2021 at 5:35:32 PM UTC-7, ******@gmail.com wrote:
> The simplest way to improve 6502 in the context of high level languages is to make all registers
> and operations 16 bit, sacrificing 8 bit performance. This should allow to obtain code density
> comparable to VMs.

65org16 does something like that, by widening all bytes and data paths to 16-bits and leaving pretty
much everything else alone.

https://github.com/BigEd/CPU-65Org16

Michael Barry <barrym95838@yahoo.com> schrieb:
> On Tuesday, August 3, 2021 at 5:35:32 PM UTC-7, ******@gmail.com wrote:
>> The simplest way to improve 6502 in the context of high level languages is to make all registers
>> and operations 16 bit, sacrificing 8 bit performance. This should allow to obtain code density
>> comparable to VMs.
>
> 65org16 does something like that, by widening all bytes and data paths to 16-bits and leaving pretty
> much everything else alone.

> https://github.com/BigEd/CPU-65Org16

Looking at this, it doesn't have a way to deal with bytes, so you
would have to execute eight shift instructions to get to the high
byte of a word. That does not sound practical.

> A lot of talk about a better 6502, but having spent
> a couple of years programming asm for 6502 based
> embedded systems, the architecture had more than enough
> capability for the task. The indirect addressing modes
> in particular, provided a sort of virtualised 16 bit
> operation capability. Never had any issues with
> page zero usage, or running out of space. We built
> complex systems using 6502, some of which are
> probably still in use.
So I have few questions for you:
1) What is the code-to-data ratio in the embedded 6502?
2) What is the ratio of 16-bit to 8-bit computations?
3) How often the performance was a limiting factor?
4) Could the 16-bit 6502 be a more convenient option (with support for 8 bit data)?
> All in all, brilliant piece of design work for it's
> time...
I wonder if we could do much better using modern layout optimization tools.

>
> Chris

On Wednesday, August 4, 2021 at 12:01:08 PM UTC-5, pec...@gmail.com wrote:
> > A lot of talk about a better 6502, but having spent
> > a couple of years programming asm for 6502 based
> > embedded systems, the architecture had more than enough
> > capability for the task. The indirect addressing modes
> > in particular, provided a sort of virtualised 16 bit
> > operation capability. Never had any issues with
> > page zero usage, or running out of space. We built
> > complex systems using 6502, some of which are
> > probably still in use.
> So I have few questions for you:
> 1) What is the code-to-data ratio in the embedded 6502?
> 2) What is the ratio of 16-bit to 8-bit computations?
> 3) How often the performance was a limiting factor?
> 4) Could the 16-bit 6502 be a more convenient option (with support for 8 bit data)?
> > All in all, brilliant piece of design work for it's
> > time...
> I wonder if we could do much better using modern layout optimization tools.
<
I have been watching this thread develop with various people proposing
adding this or dropping that. I have slowly come to the following conclusion:
<
a) this was a design that prospered in the realm of embarrassing frugality,
There is not a SINGLE flip-flop in the design, there is no clock tree, there is
no scan path,...........it is delicious in its simplicity.
<
b) modern tools know nothing of this realm and impose a huge burden on
designs targeting this corner of the design space.
<
c) the concept that we, who have exploited billions of transistors, could perform
well in the ares of a handful of thousands of transistors is ludicrous. That we
who have dozens of metal layers could "do" a design with only 1 is also ludicrous.
No modern "tool" software can operate in this realm
<
d) Modern design software (Verilog, simulators, FPGA breadboarding)
is all designed to help those with industrial scale issues, not those of
"significantly smaller than a modern hobbiest"
<
I take my hat off to them; And give them a well deserved bow !
<
{All of the above apply to me as much as anyone else in this forum--excepting
perhaps BGB}.
>
> >
> > Chris

On 08/04/21 18:01, pec...@gmail.com wrote:

> So I have few questions for you:
> 1) What is the code-to-data ratio in the embedded 6502?

No idea, not sure if anyone considered such issues at the
time. While it only had a 16 bit address space, program
memory eproms were typically 1k or 2K x 8 and the programs
were quite small. For those really fluent in asm, a lot
can be done in just a few lines of code.

> 2) What is the ratio of 16-bit to 8-bit computations?

Again, no idea, but like pointers and C, once the indirect
modes were understood, it opened up a world of possibilities
in terms of data structures, lists and more.

> 3) How often the performance was a limiting factor?

Never on the projects I worked on. One such app was frame
accurate video controller for medical imaging. The frame
pulse synced timecode function for that used two interrupt
driven timers to generate the phase encoded waveform in
real time. Corrections were needed to take account of the
interrupt processing times, but that was the closest
we got to a hard limit on capability.

> 4) Could the 16-bit 6502 be a more convenient option (with support for 8 bit data)?

Western Design Center did a 16 bit version, as used in the
Apple IIC, but never used it in any project. For the
sort of embedded app worked on here, 6502 was more than
capable of getting the job done. Expectations were
different, in that most programming was done in asm. Did
buy the Manx C compiler or the Apple II later, but the output
code from that was dreadful, pages and pages of really bad
code that showed no understanding of the underlying strengths
of the architecture. Glacial in performance as well.

>> All in all, brilliant piece of design work for it's
>> time...
> I wonder if we could do much better using modern layout optimization tools

Iirc, it has been used as a core in some gate arrays, but
don't have details.

So much capability in modern micros, with compilers often producing
a single line of asm per line of C. A different world altogether...

Chris

>
>>
>> Chris

On Thu, 05 Aug 2021 00:14:55 +0100, chris <chris-nospam@tridac.net>
wrote:

>> 4) Could the 16-bit 6502 be a more convenient option (with support for 8 bit data)?
>
>Western Design Center did a 16 bit version, as used in the
>Apple IIC, ...

The Apple //c used a WDC 65c02, but that chip was not 16-bit.

WDC had two 16-bit versions - 65c816 and 65c802 - which internally
were identical but differed in packaging: the 65c816 was 44-pin QFP,
the 65c802 was a 40-pin DIP that was pin and signal compatible with
65c02.

Both chips were selectable for 8 or 16 bit mode. In 8-bit mode they
behaved like a 65c02 but with some additional reg->reg and block move
instructions.

In 16-bit mode A,X,Y,D and S were extended to 16 bits, and two 8-bit
bank registers: PBR and DBR, allowed for 24-bit code and/or data
addresses. The stack and direct page were hard-wired to bank 00 [1st
64KB of memory], but were relocatable within the bank, and the stack
(theoretically at least) could expand up to 64KB.

Compilers for these chips typically overlaid the direct page on the
current stack frame, (ab)using the D register as a frame pointer.

Even the 65c802 programs could use 24-bit addresses - they just
wouldn't work outside of bank 00. For signal compatibility with 65c02
the 65c802 brought only the lower 16 address bits to the bus.

The 65c816 had additional signal lines for use with external cache.
Some of the Apple //gs accelerator boards did make use of them.

>... but never used it in any project. For the
>sort of embedded app worked on here, 6502 was more than
>capable of getting the job done. Expectations were
>different, in that most programming was done in asm. Did
>buy the Manx C compiler for the Apple II later, but the output
>code from that was dreadful, pages and pages of really bad
>code that showed no understanding of the underlying strengths
>of the architecture. Glacial in performance as well.

I also used the Manx compiler. The code quality certainly was not
comparable to good asm, but I have to question your characterization
of it as 'dreadful'.

Given the time period (~1986) and the limitations of the target, I
would characterize Manx's compiler as 'not bad': it generated
reasonably straight forward templated code, and then performed some
peep-hole optimization on the assembler.

I particularly appreciated Manx's ability to mix bytecode and native
code in the same program - letting you tune the program for function
vs speed without resorting to overlays (which also were supported).
The bytecode interpreter was pretty well designed with six 16-bit
registers, was reasonably quick (again considering the target), and
had its own assembler so you could write code for it directly.

Manx was usable with 2 floppy drives: each pass of its compiler was a
separate program, so you could run one pass over all the source (or
IR) files before having to change program disks for the next pass.
Assuming all the source and temp files fit onto 1 data disk, building
a program from multiple source files required only a couple of disk
swaps.

Manx's bytecode compiler fit onto the same program disk as the linker,
so it could be used without any disk swapping, allowing at least to
check your code would compile before mucking around with the native
compiler.

Another plus was that Manx bytecode was portable to any supported
chip. They had compilers for 6502, 6800, Z80 and 8086/88 that all
recognized the same object and overlay file formats. You could
compile a program to bytecode on /any/ supported chip and then link
with a target specific library to create a working program. Overlay
files that contained only bytecode were directly usable by any target.

Orca's native compiler unquestionably produced better code, but it
used overlays loaded from multiple program disks - using it from
floppies [though technically possible] required multiple disk swaps
/per/ source file ... it simply was impractical to use sans hard disk.
It also was a /lot/ more expensive than Manx and there was no bytecode
version.

Using Orca on Apple // was similar to using Whitesmith on Z80 ... a
painful experience at best.

YMMV, but I managed quite a lot with the Manx compiler.

On 08/05/21 18:28, George Neuner wrote:

>
>
> YMMV, but I managed quite a lot with the Manx compiler.

Many of those who worked with microprocessors in the late 70's
came to the subject from an electronics hardware background, with
little or no computer science knowledge, nor appreciation of data
structures, algorithms, or os theory. That was the situation here.
Primarily analog hardware design background, with some digital
logic design using ssi devices. The solution was to buy
comp sci books to get a proper grounding in the subject. Bought
a Kim 1 working in the US in 1977 for $100, from memory and what
a subversive little machine that was, in terms of effect.

You saw far more in the wdc effort than I did and the same for
the Manx C complier. 6502 was off the shelf here in the uk, well
supported and understood, while wdc was far away and don't
remember if there was even a uk agent for the devices. Iirc, I
did a grey import to the uk for Manx C, probably after seeing
it advertised in Byte mag, and also having been fired up by
things like the AT&T programmers workbench report, blue book,
which seemed like another world. Still an asm programmer, didn't
really have the knowledge base at the time to make best use of
it, wasn't impressed with the code it produced and eventually
gave up. Of course, that is not the only metric and perhaps I
should have made more effort with it. Looking back, the 6502
was a serious effort to get as much minicomputer capability in
to a cheap 8 bit machine and that and other 8 bit micros started
the wave that killed the mini computer market.

After all that, Motorola released the 68000 series, and the
world changed forever...

On Thursday, August 5, 2021 at 6:01:29 PM UTC-5, chris wrote:
> On 08/05/21 18:28, George Neuner wrote:
>
> >
> >
> > YMMV, but I managed quite a lot with the Manx compiler.
> Many of those who worked with microprocessors in the late 70's
> came to the subject from an electronics hardware background, with
> little or no computer science knowledge, nor appreciation of data
> structures, algorithms, or os theory.
<
These were the very same people who invented the XOR trick with
linked list pointers--saving ½ of the pointer space in data structures..
<
> That was the situation here.
> Primarily analog hardware design background, with some digital
> logic design using ssi devices. The solution was to buy
> comp sci books to get a proper grounding in the subject. Bought
> a Kim 1 working in the US in 1977 for $100, from memory and what
> a subversive little machine that was, in terms of effect.
>
> You saw far more in the wdc effort than I did and the same for
> the Manx C complier. 6502 was off the shelf here in the uk, well
> supported and understood, while wdc was far away and don't
> remember if there was even a uk agent for the devices. Iirc, I
> did a grey import to the uk for Manx C, probably after seeing
> it advertised in Byte mag, and also having been fired up by
> things like the AT&T programmers workbench report, blue book,
> which seemed like another world. Still an asm programmer, didn't
> really have the knowledge base at the time to make best use of
> it, wasn't impressed with the code it produced and eventually
> gave up. Of course, that is not the only metric and perhaps I
> should have made more effort with it. Looking back, the 6502
> was a serious effort to get as much minicomputer capability in
> to a cheap 8 bit machine and that and other 8 bit micros started
> the wave that killed the mini computer market.
>
> After all that, Motorola released the 68000 series, and the
> world changed forever...

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Thursday, August 5, 2021 at 6:01:29 PM UTC-5, chris wrote:
>> On 08/05/21 18:28, George Neuner wrote:
>>
>> >
>> >
>> > YMMV, but I managed quite a lot with the Manx compiler.
>> Many of those who worked with microprocessors in the late 70's
>> came to the subject from an electronics hardware background, with
>> little or no computer science knowledge, nor appreciation of data
>> structures, algorithms, or os theory.
><
> These were the very same people who invented the XOR trick with
> linked list pointers--saving ½ of the pointer space in data structures.

I didn't know that one - nice hack.

You could use this for Fortran's unformatted files too, which are
(usually) similar to doubly linked lists except that it uses the
record length and not the address of the following data.

Maybe it's a good thing that I didn't learn about this before.

On 06.08.2021 07:50, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
> I didn't know that one - nice hack.
>
> You could use this for Fortran's unformatted files too, which are
> (usually) similar to doubly linked lists except that it uses the
> record length and not the address of the following data.
>
> Maybe it's a good thing that I didn't learn about this before.
>

It is only useful when you are iterating the list from one or the other
end and know where you came from.

If you just pick a node (e.g. by a pointer from outside), and then want
to find an adjacent node, insert or delete one, you're stuck.

As a summary: Nice, but seldom useful.

--
Regards,
Bernd

On 06/08/2021 07:50, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Thursday, August 5, 2021 at 6:01:29 PM UTC-5, chris wrote:
>>> On 08/05/21 18:28, George Neuner wrote:
>>>
>>>>
>>>>
>>>> YMMV, but I managed quite a lot with the Manx compiler.
>>> Many of those who worked with microprocessors in the late 70's
>>> came to the subject from an electronics hardware background, with
>>> little or no computer science knowledge, nor appreciation of data
>>> structures, algorithms, or os theory.
>> <
>> These were the very same people who invented the XOR trick with
>> linked list pointers--saving ½ of the pointer space in data structures.
>
> I didn't know that one - nice hack.
>

If you want to see some nice hacks with 6502 code, look at the BBC
Micro. These were amazing pieces of engineering - in the days when
8-bit home computers ran BASIC (or in one unusual case, FORTH), the BBC
Micro had a flexible operating system that supported ROMs for different
languages and different file systems. One of the machine code hacks I
remember from it was that the multiplication table (the 6502 didn't have
a hardware multiplier, so a lookup table was used) overlapped some of
the character maps for the screen. That was an engineering solution,
not a computer science solution!

On 08/06/21 10:56, David Brown wrote:
> On 06/08/2021 07:50, Thomas Koenig wrote:
>> MitchAlsup<MitchAlsup@aol.com> schrieb:
>>> On Thursday, August 5, 2021 at 6:01:29 PM UTC-5, chris wrote:
>>>> On 08/05/21 18:28, George Neuner wrote:
>>>>
>>>>>
>>>>>
>>>>> YMMV, but I managed quite a lot with the Manx compiler.
>>>> Many of those who worked with microprocessors in the late 70's
>>>> came to the subject from an electronics hardware background, with
>>>> little or no computer science knowledge, nor appreciation of data
>>>> structures, algorithms, or os theory.
>>> <
>>> These were the very same people who invented the XOR trick with
>>> linked list pointers--saving ½ of the pointer space in data structures.
>>
>> I didn't know that one - nice hack.
>>
>
> If you want to see some nice hacks with 6502 code, look at the BBC
> Micro. These were amazing pieces of engineering - in the days when
> 8-bit home computers ran BASIC (or in one unusual case, FORTH), the BBC
> Micro had a flexible operating system that supported ROMs for different
> languages and different file systems. One of the machine code hacks I
> remember from it was that the multiplication table (the 6502 didn't have
> a hardware multiplier, so a lookup table was used) overlapped some of
> the character maps for the screen. That was an engineering solution,
> not a computer science solution!
>

The aim65 from Rockwell had optional roms for assembler, forth, basic
and perhaps more, but developed a couple of products using the single
line assembler in the monitor roms. Had to go back and fill in all the
branch targets, a sort of manual 2nd pass, but worked well enough to
get the job done. The BBC micro was a clever design though, but
never worked on one here.

Some clever stuf in the Apple II io page roms, where Wozniac
saved single bytes of code space by fixing a relative branch to
form a new instruction, or a branch target. Io pages were just 256
bytes each, so not much free space for driver code...

On 06/08/2021 14:17, chris wrote:
> On 08/06/21 10:56, David Brown wrote:
>> On 06/08/2021 07:50, Thomas Koenig wrote:
>>> MitchAlsup<MitchAlsup@aol.com>  schrieb:
>>>> On Thursday, August 5, 2021 at 6:01:29 PM UTC-5, chris wrote:
>>>>> On 08/05/21 18:28, George Neuner wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> YMMV, but I managed quite a lot with the Manx compiler.
>>>>> Many of those who worked with microprocessors in the late 70's
>>>>> came to the subject from an electronics hardware background, with
>>>>> little or no computer science knowledge, nor appreciation of data
>>>>> structures, algorithms, or os theory.
>>>> <
>>>> These were the very same people who invented the XOR trick with
>>>> linked list pointers--saving ½ of the pointer space in data structures.
>>>
>>> I didn't know that one - nice hack.
>>>
>>
>> If you want to see some nice hacks with 6502 code, look at the BBC
>> Micro.  These were amazing pieces of engineering - in the days when
>> 8-bit home computers ran BASIC (or in one unusual case, FORTH), the BBC
>> Micro had a flexible operating system that supported ROMs for different
>> languages and different file systems.  One of the machine code hacks I
>> remember from it was that the multiplication table (the 6502 didn't have
>> a hardware multiplier, so a lookup table was used) overlapped some of
>> the character maps for the screen.  That was an engineering solution,
>> not a computer science solution!
>>
>
>
> The aim65 from Rockwell had optional roms for assembler, forth, basic
> and perhaps more, but developed a couple of products using the single
> line assembler in the monitor roms. Had to go back and fill in all the
> branch targets, a sort of manual 2nd pass, but worked well enough to
> get the job done. The BBC micro was a clever design though, but
> never worked on one here.
>
> Some clever stuf in the Apple II io page roms, where Wozniac
> saved single bytes  of code space by fixing a relative branch to
> form a new instruction, or a branch target. Io pages were just 256
> bytes each, so not much free space for driver code...
>

I used to have to do that kind of stuff for some of the brain-dead 8-bit
microcontrollers. I remember that on the COP8, you would do table
lookup using a "load indirect" instruction but it would only work within
a 256-byte code page. So if you wanted a 256-entry lookup table, you
had to combine the load indirect and its following "return" inside the
data table somehow. I solved that on a couple of occasions by adding an
offset to all the entries in a table so that the instructions I needed
turned up in the table - and then compensated after reading the table.
This kind of thing is fun in its way, but I am not sorry to see the back
of such chips.

piątek, 23 lipca 2021 o 12:59:30 UTC+2 Thomas Koenig napisał(a):
> Another direction for retro-architectures... I've been looking
> at the 6502 a bit, and it really is quite an interesting design.
> Squeezing the functionality of a CPU into ~3500 transistors (plus
> ~1000 transistors used as resistors) was quite an achievement.
>
> Could we do better knowing what we know now?
What about manufacturing improvements?
Why couldn't we use a second layer of metallic connections?
The additional cost is 33% (or less) of the lithography phases, but we can significantly reduce the die size!
It should pay off.
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

On Friday, August 6, 2021 at 3:47:02 PM UTC-5, pec...@gmail.com wrote:
> piątek, 23 lipca 2021 o 12:59:30 UTC+2 Thomas Koenig napisał(a):
> > Another direction for retro-architectures... I've been looking
> > at the 6502 a bit, and it really is quite an interesting design.
> > Squeezing the functionality of a CPU into ~3500 transistors (plus
> > ~1000 transistors used as resistors) was quite an achievement.
> >
> > Could we do better knowing what we know now?
> What about manufacturing improvements?
> Why couldn't we use a second layer of metallic connections?
> The additional cost is 33% (or less) of the lithography phases, but we can significantly reduce the die size!
> It should pay off.
> >
> > "Better" could of course mean different things - more instructions
> > per cycle, possibility of higher frequency, higher code density,
> > easier programming (programming the 6502 was not easy, especially
> > on the C-64 where Commodore had used up almost all of the zero
> > page for its Basic - I hardly ever used the X register).
> >
> > The boundary conditions were of course severe. 16 bit address
> > bus, combined program and data bus of 8 bit. At least memory
> > was rather fast and could be accessed once per cycle without
> > problems (and even with the possibility of another, interleaved
> > access for graphics). Plus, any more transistors were bound to
> > increase the size and decrease the yield, leading to much
> > higher cost and erosion of the competetive advantage that the
> > 6502 and its derivatives had at the time.

Looking at the 6502 and widening to 16 & 32-bits or improving overall performance:
A legacy upgrade needs to be mostly compatible with the original ISA.
In order to squeeze in the additional op-codes some "refactoring" will be
necessary? I.e. implement a superset of the original?
Almost any re-spin on newer process nodes will be faster. Per Alsup, a
re-spin on current process nodes will be miniscule. So the problem reduces
to finding a "cash cow" customer?

BTW, FPGA implementations of original can hit 200MHz and use under 500 LUTs..
This equates to less than $0.50 FPGA fabric at quantity one pricing. A 16-bit wide
version at twice that?

On 8/6/2021 3:53 PM, JimBrakefield wrote:
> On Friday, August 6, 2021 at 3:47:02 PM UTC-5, pec...@gmail.com wrote:
>> piątek, 23 lipca 2021 o 12:59:30 UTC+2 Thomas Koenig napisał(a):
>>> Another direction for retro-architectures... I've been looking
>>> at the 6502 a bit, and it really is quite an interesting design.
>>> Squeezing the functionality of a CPU into ~3500 transistors (plus
>>> ~1000 transistors used as resistors) was quite an achievement.
>>>
>>> Could we do better knowing what we know now?
>> What about manufacturing improvements?
>> Why couldn't we use a second layer of metallic connections?
>> The additional cost is 33% (or less) of the lithography phases, but we can significantly reduce the die size!
>> It should pay off.
>>>
>>> "Better" could of course mean different things - more instructions
>>> per cycle, possibility of higher frequency, higher code density,
>>> easier programming (programming the 6502 was not easy, especially
>>> on the C-64 where Commodore had used up almost all of the zero
>>> page for its Basic - I hardly ever used the X register).
>>>
>>> The boundary conditions were of course severe. 16 bit address
>>> bus, combined program and data bus of 8 bit. At least memory
>>> was rather fast and could be accessed once per cycle without
>>> problems (and even with the possibility of another, interleaved
>>> access for graphics). Plus, any more transistors were bound to
>>> increase the size and decrease the yield, leading to much
>>> higher cost and erosion of the competetive advantage that the
>>> 6502 and its derivatives had at the time.
>
> Looking at the 6502 and widening to 16 & 32-bits or improving overall performance:
> A legacy upgrade needs to be mostly compatible with the original ISA.
> In order to squeeze in the additional op-codes some "refactoring" will be
> necessary? I.e. implement a superset of the original?
> Almost any re-spin on newer process nodes will be faster. Per Alsup, a
> re-spin on current process nodes will be miniscule. So the problem reduces
> to finding a "cash cow" customer?

If you use width-tagging metadata then you don't even have to enlarge
the instruction set, except for loads where you need to handle bigger
offsets anyway.

On Friday, August 6, 2021 at 6:05:09 PM UTC-5, Ivan Godard wrote:
> On 8/6/2021 3:53 PM, JimBrakefield wrote:
> > On Friday, August 6, 2021 at 3:47:02 PM UTC-5, pec...@gmail.com wrote:
> >> piątek, 23 lipca 2021 o 12:59:30 UTC+2 Thomas Koenig napisał(a):
> >>> Another direction for retro-architectures... I've been looking
> >>> at the 6502 a bit, and it really is quite an interesting design.
> >>> Squeezing the functionality of a CPU into ~3500 transistors (plus
> >>> ~1000 transistors used as resistors) was quite an achievement.
> >>>
> >>> Could we do better knowing what we know now?
> >> What about manufacturing improvements?
> >> Why couldn't we use a second layer of metallic connections?
> >> The additional cost is 33% (or less) of the lithography phases, but we can significantly reduce the die size!
> >> It should pay off.
> >>>
> >>> "Better" could of course mean different things - more instructions
> >>> per cycle, possibility of higher frequency, higher code density,
> >>> easier programming (programming the 6502 was not easy, especially
> >>> on the C-64 where Commodore had used up almost all of the zero
> >>> page for its Basic - I hardly ever used the X register).
> >>>
> >>> The boundary conditions were of course severe. 16 bit address
> >>> bus, combined program and data bus of 8 bit. At least memory
> >>> was rather fast and could be accessed once per cycle without
> >>> problems (and even with the possibility of another, interleaved
> >>> access for graphics). Plus, any more transistors were bound to
> >>> increase the size and decrease the yield, leading to much
> >>> higher cost and erosion of the competetive advantage that the
> >>> 6502 and its derivatives had at the time.
> >
> > Looking at the 6502 and widening to 16 & 32-bits or improving overall performance:
> > A legacy upgrade needs to be mostly compatible with the original ISA.
> > In order to squeeze in the additional op-codes some "refactoring" will be
> > necessary? I.e. implement a superset of the original?
> > Almost any re-spin on newer process nodes will be faster. Per Alsup, a
> > re-spin on current process nodes will be miniscule. So the problem reduces
> > to finding a "cash cow" customer?
> If you use width-tagging metadata then you don't even have to enlarge
> the instruction set, except for loads where you need to handle bigger
> offsets anyway.

One way to tag the data is in the address. By giving up two or three bits of address one
can tag both the data size and its type (in powers of two). Since there are usually fewer
addresses than data items one saves on memory costs. (tags use trailing zeros count
to encode type and then size; another tag bit and one can have a 3X multiplier).
However suspect Godard meant tags on the data registers and not tags in memory
(using separate loads & store instructions for each data size tag)?

David Brown wrote:
> On 06/08/2021 14:17, chris wrote:
>> The aim65 from Rockwell had optional roms for assembler, forth, basic
>> and perhaps more, but developed a couple of products using the single
>> line assembler in the monitor roms. Had to go back and fill in all the
>> branch targets, a sort of manual 2nd pass, but worked well enough to
>> get the job done. The BBC micro was a clever design though, but
>> never worked on one here.
>>
>> Some clever stuf in the Apple II io page roms, where Wozniac
>> saved single bytes  of code space by fixing a relative branch to
>> form a new instruction, or a branch target. Io pages were just 256
>> bytes each, so not much free space for driver code...
>>
>
> I used to have to do that kind of stuff for some of the brain-dead 8-bit
> microcontrollers. I remember that on the COP8, you would do table
> lookup using a "load indirect" instruction but it would only work within
> a 256-byte code page. So if you wanted a 256-entry lookup table, you
> had to combine the load indirect and its following "return" inside the
> data table somehow. I solved that on a couple of occasions by adding an
> offset to all the entries in a table so that the instructions I needed
> turned up in the table - and then compensated after reading the table.
> This kind of thing is fun in its way, but I am not sorry to see the back
> of such chips.

We still did a lot of these things for early PC code, since the only way
to add OS functionality was to write TSR drivers, and they had to fit in
memory alongside the largest documents/spreadsheets people wanted to edit.

My personal favorite was the TMKBVEGA.COM program which in just 700
bytes of resident memory provided a full Norwegian keyboard handler,
with all our special characters and key layout, along with replacement
text generator fonts for 25/43/50-line text modes.

The complexity pales in comparison with the triple-layer bootstrap code
for my MEMI-compatible executable text generator.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> The complexity pales in comparison with the triple-layer bootstrap code
> for my MEMI-compatible executable text generator.

Some more details?

Wikipedia gives me the Brunei Ministry of Energy, somehow I doubt
that this was what was meant :-)

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
>> The complexity pales in comparison with the triple-layer bootstrap code
>> for my MEMI-compatible executable text generator.
>
> Some more details?
>
> Wikipedia gives me the Brunei Ministry of Energy, somehow I doubt
> that this was what was meant :-)
>
Sorry, I swapped two letters: I meant MIME-compatible, i.e. an
executable which can only use byte values from the 70+ ascii characters
which are guaranteed to pass unmodified through all email gateways.

I wrote it to be minimally self-modifying (I got away with a single
two-byte Jcc backward branch) since it is impossible to write any form
of loop in x86 without using byte values with the high bit set.

It is also resistant to several forms of editing, most importantly it
handles having the normal CRLF line ends raplaced with unix LF, Mac CR
or even Word style one line per paragraph: Basically any zero to
two-byte sequence is allowed.

(It works this way because there is a CMP AX,CRLF 3-byte sequence which
covers the line end, this is followed by two effectively NOP bytes which
will move into the CMP immediate bytes if the line end is shortened.)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"