Jump to content
IGNORED

What's the one (or more) features you wanted the Apple II to have?


Keatah

Recommended Posts

I've recently started to learn more about programming the 658XX CPUs.

658XX code can be shorter, faster, easier to write, requires you to jump through fewer hoops for fast code, etc...

The 658XX has noticeable shortcomings vs the 6809 and 6309, but it's well ahead of the 6502.

 

Too bad the 6516 (sometimes referred to as the 6509) was never produced.

We could have seen similar features in 1979. I think having the Atari launch with that chip would have forced other companies to migrate.

 

I have thought about building a 6516 ( 6509 ) as a SoftCore on the Carte Blance II.. Just to see what it would be like....

 

Once you have one working on an FPGA, theoretically you could mount the FPGA on a 40 pin DIP and make a Replacement CPU..

 

MarkO

Link to comment
Share on other sites

I just got an old ROM 0 or ROM 1, not sure, GS! As winter approaches, I may join you.

 

Agreed. It's amazing just how many 6502's are still made and sold. Just one of these paths may have improved tons of products!

 

And dammit, the 6809 should have appeared in more places. It's such a fun chip. Beautiful. At least we got the CoCo 3. Respectable graphics, MMU, good clock. If I want my 6809 fix, that's not a bad way to go.

 

Until you update it to a 6309........ ;)

 

( I have a CoCo 1, Two CoCo 2s, and a CoCo 3, and I think I will upgrade the 2s and 3 to the 6309.. )

 

MarkO

Link to comment
Share on other sites

 

I have thought about building a 6516 ( 6509 ) as a SoftCore on the Carte Blance II.. Just to see what it would be like....

 

Once you have one working on an FPGA, theoretically you could mount the FPGA on a 40 pin DIP and make a Replacement CPU..

 

MarkO

If you do, add some new instructions for LDA & STA that don't require switching A to 16 bit mode.

That could save a lot of mode switching on the 65802 and 65816.

 

  • Like 1
Link to comment
Share on other sites

 

Until you update it to a 6309........ ;)

 

( I have a CoCo 1, Two CoCo 2s, and a CoCo 3, and I think I will upgrade the 2s and 3 to the 6309.. )

 

MarkO

The 6809 already beats the 65816 for most stuff, but the 6309 destroys it.

The 65816 screen scroll for my 64 column graphics text driver saves over 27,600 clock cycles vs the 6502.

That will be close to the 6809, but the 6309 memory move instruction moves 1 byte every 3 clock cycles.

That's 3 less than the 65816 for every two bytes and it doesn't require the loop overhead.

The 65816 MVN instruction requires 7 clock cycles per byte! Too bad they didn't get it down to 4 or less, then it would be faster than an unrolled loop.

  • Like 1
Link to comment
Share on other sites

If you do, add some new instructions for LDA & STA that don't require switching A to 16 bit mode.

That could save a lot of mode switching on the 65802 and 65816.

 

 

I haven't "messed" with the 65802/65816 at the Assembler Level...

 

What were you thinking would help??

 

I can see the 16 Bit "A Register" has a lot more "options" than the 8 Bit version?? It would make sense to have the same 16 Bit Op Code be active in 8 Bit mode..

 

MarkO

Link to comment
Share on other sites

 

I haven't "messed" with the 65802/65816 at the Assembler Level...

 

What were you thinking would help??

 

I can see the 16 Bit "A Register" has a lot more "options" than the 8 Bit version?? It would make sense to have the same 16 Bit Op Code be active in 8 Bit mode..

 

MarkO

Being able to load 8 bits while in 16 bit more or 16 bits while in 8 bit mode would eliminate having to switch back and forth which takes two instructions if you change from one to the other and back. With that overhead, you might as well just stay in the mode you are in and use other instructions to accomplish the same thing.

 

It opens up easily building 16 bit values from 8 bit data or loading to 8 bit values with one 16 bit instruction.

It would mean having to call the 16 bit register D or something like that so it knows which LDA (8 or 16 bit) to use.

  • Like 1
Link to comment
Share on other sites

A true Random Number generator that doesn't require any seeding.

 

A simple program demonstrates Applesoft BASIC's RND function is only pseudo random.

 

10 FOR A=1 TO 10

20 PRINT A

30 NEXT

 

..run it. Note the numbers, and reboot. Run it again.

 

To see it graphically you can use this program.

 

5 HGR

10 HCOLOR = 3

20 X = RND(1) * 280: Y = RND(1) * 160

30 HPLOT X,Y

40 A=A +1

50 PRINT A

60 GOTO 20

 

At 18,879 the dots will cease to fill in the black areas. Run it in Applewin to speed it up or wait (painfully) like in the old days.

 

I know about the paddles, and keyboard seeds. But what about unattended power up? I don't suppose anyone has found a source of or a way to access more entropy without user interaction in the II series?

 

But I got to thinking what about noise in the ram during power up? Surely there locations that aren't totally cleared. Or what about looking at the timing of the Disk II. All that temperature dependent rotation and stuff. yeh..

 

It may not be the high-quality Quantum noise Intel uses in their latest chips, 2 inverters in a race condition; but it would be something.

 

 

REF:

https://groups.google.com/forum/#!topic/comp.sys.apple2.programmer/TICn5PbiLkw

http://www.txbobsc.com/aal/1984/aal8405.html#a4

  • Like 1
Link to comment
Share on other sites

Computer scientists have been exploring random number generation for a long time and there is a key problem.
True random numbers can theoretically repeat and appear to be a pattern, they are not evenly distributed.

If you want unmonitored startup, you'd need to seed the random number generator with something like a real time clock.

  • Like 1
Link to comment
Share on other sites

I was afraid of that..

Random numbers are sort of the bane of game programmers. You need something fast that doesn't obviously appear to repeat quickly.

It's very tough to do. I think you are stuck with some sort of slow mathematical operation, or bit shifting, tables, etc...

Edited by JamesD
Link to comment
Share on other sites

Being able to load 8 bits while in 16 bit more or 16 bits while in 8 bit mode would eliminate having to switch back and forth which takes two instructions if you change from one to the other and back. With that overhead, you might as well just stay in the mode you are in and use other instructions to accomplish the same thing.

 

It opens up easily building 16 bit values from 8 bit data or loading to 8 bit values with one 16 bit instruction.

It would mean having to call the 16 bit register D or something like that so it knows which LDA (8 or 16 bit) to use.

 

I liked how the Hitachi 6309 Extended the Motorola 6809, and the Register Names they picked...

 

Or the Motorola 6800-08, has the Accumulator A and the Accumulator B.. So LDA could be extended to have LDB and LDAB or LDD

 

You can't get TOO Wild with this, if only Carte Blanche II users benefit.....

 

But if a FPGA could be made to emulate a ZIP-4 or ZIP-8, and have the option of a 6509/6516, that could be Dropped into an Apple. that would be something people might want.. ( Heck, this could be optimized to replace a 6510 in the C64 or for the Atari 400/800 )

 

MarkO

 

MarkO

Link to comment
Share on other sites

 

I liked how the Hitachi 6309 Extended the Motorola 6809, and the Register Names they picked...

 

Or the Motorola 6800-08, has the Accumulator A and the Accumulator B.. So LDA could be extended to have LDB and LDAB or LDD

 

You can't get TOO Wild with this, if only Carte Blanche II users benefit.....

 

But if a FPGA could be made to emulate a ZIP-4 or ZIP-8, and have the option of a 6509/6516, that could be Dropped into an Apple. that would be something people might want.. ( Heck, this could be optimized to replace a 6510 in the C64 or for the Atari 400/800 )

 

MarkO

They made a mistake with the 6309. To form Q, the W register should have been at the MSB end of D, not the LSB end.

There are several key differences.

The least significant bytes change the most when performing math and often don't impact the higher bytes. For example, if you know adding a value (8 or 16 bit) to a 32 bit value won't overflow the bottom 8 or 16 bits, you can use a single byte 8 or 16 bit opcode to perform the math and the 32 bit number is still correct.

With their implementation, you have to use a 2 byte opcode.

You can also load an 8 or 16 bit variable with a single byte opcode, and extend it to 32 bits instead of using a 2 byte opcode. (typecasting)

This could lead to quite a few compiler optimizations for a 6309 code generator under the right conditions as well as faster hand built assembly.

Clock cycles add up.

I thought of building a 6409 with that and a few more 32 bit instructions.

 

LDB, STB, LDAB, STAB, PHB, PLB... would probably be the minimum extensions I'd add for the 6516 .

That could offer several optimizations over the 65802.

AB is definitely better than using D... you can STAB memory and hardware. :D

I really want to implement a MEH instruction, but I'm not sure what it would represent yet.

 

I have another mod that would require the Cart Blanche... but I need to look at the docs to get the hardware to build.

It would also require some software support, so lots of work.

Link to comment
Share on other sites

  • 3 weeks later...

Beagle Basic supports both...but IMO an ELSE instruction is actually superfluous (a GOTO at the end of your IF-THEN accomplishes the same thing).

Not the same. Having an ELSE statement reduces code size and number of lines.

Fewer lines mean quicker searches for lines for GOTOs and GOSUBs.

Link to comment
Share on other sites

In moving from the Apple I to the Apple II or from the II to the II+, Apple should have fixed the video memory layout to sequential addresses.

 

Well, Apple I did not have non-sequential video memory addresses. In fact its video memory was not addressable at all. It was Sequential Access Memory in the form of shift registers. To display a character on the screen, you would write it to the PIA after waiting as long as 1/60 second for the previous character to be accepted. The display routine was tiny:

ECHO BIT DSP
     BMI ECHO
     STA DSP
     RTS

Apple II's screen addressing was not broken. It was cleverly designed to adequately refresh the DRAM while displaying video. Woz has said his goal was not to minimize chip count, but to minimize pin count.

 

Woz was a master not only of hardware but of software as well. He designed both, so he could choose where to draw the line between them. His ROM routine to convert screen line number to address, BASCALC, is only 25 bytes long. Early on, his goal was to minimize the size of his software, not to maximize its speed. 1 MHz, with no wait states for video and refresh, was already fast enough. Fewest pins and fewest bytes made him happy.

 

As for changing it between the II and II+, that would have been just a bad idea for compatibility reasons.

  • Like 4
Link to comment
Share on other sites

Well, there is one advantage to the current scheme. Animations that aren't synced to the display show tearing and draw artifacts.

 

These can end up well distributed, due to the goofy order.

 

While it's slower to draw, or a lot more complex to draw (depending on what people do), the screen doesn't require DMA, which is a nice overall gain. Isn't that something like 7 percent?

 

For all the warts, we do get the full 1mhz of benefit, and a simple, baseline computer. No interrupts, no DMA in the basic system. To me, that seems like very wise choices given all that has been added on and how useful the computer ended up being.

 

Apple 8 bit computers are great workstation type machines.

Link to comment
Share on other sites

I had forgotten about the Apple I display using a PIA.

 

Could have been a soft-switch. Same RAM locations, etc... just change the display order.

That sounds like something that would have come years later.

You can refresh RAM with the screen refresh without the screwy screen memory layout.
Now I think you could do it with just a ROM and a little logic to translate some address lines and provide the right chip select order for all memory accesses.
Back then? I don't know. I suppose you could have some additional logic and two translation tables in ROM for both modes.

I don't see the compatibility as such a big issue because the II+ already broke compatibility with the II when it was released.
It dropped Integer BASIC and you couldn't run anything that required it, ROM calls to it, or the programmer's utilities ROM.
Compatibility was already largely out the window in that respect.
Plus, any text software using the system monitor calls for I/O would have been compatible.

Link to comment
Share on other sites

You can refresh RAM with the screen refresh without the screwy screen memory layout.

 

oh yea totally, but it goes back to woz being a young woz, and doing what young woz does best, making things a little more complicated to save some insignifigant thing in his mind was HUGE

 

as also ADB, wow what a pain in the ass, why? dunno to save a wire in the cable, even though the connetors and cables had that extra wire which was later squandered on keyboard power buttons?

 

woz ... brilliant, almost too much

Link to comment
Share on other sites

<< SNIP >>

 

But if a FPGA could be made to emulate a ZIP-4 or ZIP-8, and have the option of a 6509/6516, that could be Dropped into an Apple. that would be something people might want.. ( Heck, this could be optimized to replace a 6510 in the C64 or for the Atari 400/800 )

 

MarkO

It appears that "someone" has a solution......

 

The GODIL...

 

 

MarkO

  • Like 3
Link to comment
Share on other sites

FWIW, here are some of the original magazine articles on the 6509/6516 in 'MICRO The 6502 Journal'.

There were 30 opcodes that were to take one less clock cycle than the 6502. That alone would have probably offered a 5% or better speedup.
Page 7:
https://archive.org/details/micro-6502-journal-21


It was supposedly only going to be source compatible with the 6502 but they were going to try to change that according to the article.
It switched between 8 and 16 bit modes for X, Y, and SP like the 65816, but several instructions also switched so you could INC a 16 bit number in memory for example.
16 bit relative jumps were to be supported for position independent code.
It had something similar to the LEA instruction on the 6809.
Page Zero was replaced with the Direct Page like the 6809.
And I believe it had additional stack instructions including the ability to PUSH/PULL multiple registers at a time with a single instruction.
The two major omissions I see were no mention of stack relative addressing, and no multiply instruction.
In spite of those omissions, it would have been a beast of a CPU in the 8 bit world

Page 36:
https://archive.org/details/micro-6502-journal-23

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...