DREAM 6800 (now 6809) re-Creation

[djrm]

Looking carefully at magnified screen photo it looks like the active pixels are black with a green surround, obviously that isn't the only problem. I think the user entered data ( or something ) is meant to be stored at Ox238 onwards, perhaps seeing random noise from there on the display, but it's being drawn and erased, odd.

[Editor]

Looking carefully at magnified screen photo it looks like the active pixels are black with a green surround, obviously that isn't the only problem. I think the user entered data ( or something ) is meant to be stored at Ox238 onwards, perhaps seeing random noise from there on the display, but it's being drawn and erased, odd.

I found the bug! Yay! (and a big thank you for detecting this oversight!)

I missed one of the 6809 'S' Stack Pointer decrements!

You see, one of the differences between 6800 & 6809, is that on the 6800 the Stack Pointer points to the next entry, whereas on the 6809 the Stack Pointer points to the last entry!

So, the 6809 conversion oversight (that I missed) was in the STORV routine (funnily enough, I'd corrected the similar LOADV routine).

STORV relates to the FX55 instruction (MI = V0:VX).

New CHIPOS ROM images will be commited to Github shortly...

[djrm]

Great news, thank you. I'll try it again when I get time.

[Editor]

Great news, thank you. I'll try it again when I get time.

Corrected CHIPOS 6809 ROM images, and updated CHIPOS source code (1 line), has now been committed to Github.

Please let me know when you've had a chance to confirm all is now working as expected (Life is back to normal?).

[Editor]

Wow. This Life program is really cool. I'm getting some awesome changing patterns!

Just remember to change to 64x32 mode for the original program (as it stands), so you fill the screen (i.e. 001C = 02).

[djrm]

Today I made my keyboard better:

Better than having a crib-sheet on my desk!
Does it count as minimalist?

I'll try the new code tomorrow.
Best regards, David.

[Editor]

Here's mine in operation: Life (as we know it):

https://youtu.be/QngiqFFHn3M

[djrm]

Please let me know when you've had a chance to confirm all is now working as expected (Life is back to normal?).

It's alive, it's moving, it's alive, it's alive, it's alive, it's alive, IT'S ALIVE!

Edit:
An interesting repeating pattern is easily started by inputting a single line of ten on pixels entered starting at co-ordinates 4,3 continuing to 4,C

https://youtu.be/tWXCo78lozc?si=A0okyTdmpluG8k3h
Initially I thought there was a fault causing the display to stop updating from time to time, it seems this is intentional. An instruction at address $00ba decrements a counter and jumps back to the key entry section. I disabled this by changing the code to decrement 0 instead - it runs continually.
It would be better if the display could use the hi-res mode to allow more interesting patterns to be input, I think this would be quite complicated to achieve.
The 'snow' is a bit disconcerting, it is occuring during the scan of existing pixels, the screen update occurs quite quickly after the calculation phase.
n.b. My system is running at 1MHz (4MHz crystal) with a vanilla 6809. I tried it at 2MHz and everything appeared ok.
Best regards, David.

[Editor]

Initially I thought there was a fault causing the display to stop updating from time to time, it seems this is intentional. An instruction at address $00ba decrements a counter and jumps back to the key entry section. I disabled this by changing the code to decrement 0 instead - it runs continually.

Yes, I noted in the Dreamer instructions it was written to allow only a 255 iteration maximum. Going forever does seem a logical option (given that a reset can obviously also stop it).

It would be better if the display could use the hi-res mode to allow more interesting patterns to be input, I think this would be quite complicated to achieve.

I think the main challenge is that going from 16x8 cells to 32x16 would require (at first thought), a 2 digit X coordinate.

Other than that, it would probably just require some changes to Skip instructions (e.g. 20 & 40 tests, to instead be 40 & 80).

The 'snow' is a bit disconcerting, it is occuring during the scan of existing pixels, the screen update occurs quite quickly after the calculation phase.

Yes. The snow is simply because they are using the XOR display logic to detect the cell existance in each surrounding cell position.
i.e. By displaying a single dot, checking for colision (VF), and then re-displaying the dot (to revert the pixel).

This is indeed disconcerting, but at least it's not due to any display update clash.

I guess that was just the way they chose to do it. The alternative would have been to create a memory buffer of the cell locations, which would have been a lot tidier (visually). But, those were early times, and programmers were just learning the ropes!

n.b. My system is running at 1MHz (4MHz crystal) with a vanilla 6809. I tried it at 2MHz and everything appeared ok.

Awesome. I didn't even try 1Mhz, as I was always running at 2Mhz (and I have programmed CHIPOS09 300 baud software delays based on a 2Mhz clock).

Curious if DREAM Invaders09 works okay at 1Mhz, or, is it too slow?

[djrm]

Looking through my parts draws I've found a plcc 63c09 and dil adapter I bought from you with my keyboard. I'd forgotten I had it, I'll try invaders faster AND slower. Just took delivery of some 68b50 chips to go with it too. David.