L System 256 colour demo + screen transitions

[Hurray Banana]

This is a bummer but does not detract from your excellent efforts ade.

I'll get some eproms for my board so I can also do some testing for you mate.

maybe I should release the roms for my two simple pacman scrolling demos

 

[cmonkey]

Small update. Now when you press P1 START to swap palettes during the palette rotation section of the demo the big-ass scrolly text changes accordingly to either '220 colours!' or '256 colours!'.

I'm not gonna spend any more time on this demo now. Time to move on and work on the game.

Eric - you should defo release your Pac-Man scrolling demos, they were huge technological achievements if you ask me. Personally I'd never seen full screen scrolling text on Pac-Man hardware before you came along and blew all hardware limitations out of the water.

https://www.ukvac.com/forum/data/uploads/1497/ic10_256_demo.zip

 

[Hurray Banana]

I'll dig out the rom data. I have a horrible habit of butchering one project to start another without backing up first

 

[Robert]

This sounds very interesting...

@cmonkey: thanks for the adjustment, i'll add that in now.

 

[ben76]

If you're passing your pile of scrappers and happen to see a socketed YM2203 then pull it and let me know your paypal so that I can stick you a few quid in.  But don't go out of your way if you're not passing specifically dude.

our interweb has gone Pete tong here luckily I have phone interweb! but found these in a spares box. Both untested but send me your address and I'll post em out



If you need any other chips lmk as I have loads of spares

- Ben

 

[cmonkey]

I've been doing a *lot* of digging around in the L System tonight and I've come to the conclusion that the 512 bytes of palette ram MUST be stored internally in the TC0090LVC and is NOT stored in the 4 x 32Kb SRAMs. I did this by replacing the L System's 4 x 32Kb SRAMs with 4 x 32Kb NVRAMs (DS1230Y), writing lots of different, short test programs to write various values through the mapped memory ranges and then dumping the contents of the NVRAMs after each test. I know now exactly how the pages are mapped in the 4 x 32Kb rams. Each 32Kb ram holds every fourth byte of data as seen in a linear map.

E.g. byte @ offset 0 in IC1 holds byte mapped to $c000

byte @ offset 0 in IC2 holds byte mapped to $c001

byte @ offset 0 in IC3 holds byte mapped to $c002

byte @ offset 0 in IC4 holds byte mapped to $c003

byte @ offset 1 in IC1 holds byte mapped to $c004

byte @ offset 1 in IC2 holds byte mapped to $c005

byte @ offset 1 in IC3 holds byte mapped to $c006

byte @ offset 1 in IC4 holds byte mapped to $c007

and so on

Each 128 bytes of sram is split into 32 x 4 bytes slices, each slice represents 4 bytes from a page in an 'every fourth byte' configuration. (e.g. IC1 holds bytes mapped to $c000/$c004/$c008/$c00c, IC2 holds bytes mapped to $c001/$c005/$c009/$c00d, etc). This pattern is repeated every 128 bytes throughout each ram.

Hence each 32Kb sram holds one quarter of each of the 32 available 4Kb pages. So when you combine all 4 x 32Kb srams you get the full 32 x 4Kb pages.

32768 / 128 = 256 slices

Each slice holds 4 bytes of each of the 32 pages

256 * 4 = 1024 bytes

4 rams in total

1024 * 4 = 4096 bytes (the size of each page)

Nowhere during my extensive testing did I see any evidence of palette ram data in the NVRAMs, even though palette ram was banked into CPU addressable space in all tests that I did. This leads me to believe that the palette ram MUST be internal to the CPU package and banking it in merely redirects palette ram reads/writes to the internal CPU palette ram rather than the external srams. This kind of makes sense as palette ram is usually the last thing that tile/sprite data passes through before being output to the edge connector/video connector and because the RGB data is output directly from the TC0090LVC to the edge connector (via 3 transistors/6 resistors) it make sense to have the palette ram internal to the CPU for speed.

Kind of makes me want to get a TC0090LVC decapped to prove that I'm right....

 

[Hurray Banana]

I've been doing a *lot* of digging around in the L System tonight and I've come to the conclusion that the 512 bytes of palette ram MUST be stored internally in the TC0090LVC and is NOT stored in the 4 x 32Kb SRAMs. I did this by replacing the L System's 4 x 32Kb SRAMs with 4 x 32Kb NVRAMs (DS1230Y), writing lots of different, short test programs to write various values through the mapped memory ranges and then dumping the contents of the NVRAMs after each test. I know now exactly how the pages are mapped in the 4 x 32Kb rams. Each 32Kb ram holds every fourth byte of data as seen in a linear map.

E.g. byte @ offset 0 in IC1 holds byte mapped to $c000

byte @ offset 0 in IC2 holds byte mapped to $c001

byte @ offset 0 in IC3 holds byte mapped to $c002

byte @ offset 0 in IC4 holds byte mapped to $c003

byte @ offset 1 in IC1 holds byte mapped to $c004

byte @ offset 1 in IC2 holds byte mapped to $c005

byte @ offset 1 in IC3 holds byte mapped to $c006

byte @ offset 1 in IC4 holds byte mapped to $c007

and so on

Each 128 bytes of sram is split into 32 x 4 bytes slices, each slice represents 4 bytes from a page in an 'every fourth byte' configuration. (e.g. IC1 holds bytes mapped to $c000/$c004/$c008/$c00c, IC2 holds bytes mapped to $c001/$c005/$c009/$c00d, etc). This pattern is repeated every 128 bytes throughout each ram.

Hence each 32Kb sram holds one quarter of each of the 32 available 4Kb pages. So when you combine all 4 x 32Kb srams you get the full 32 x 4Kb pages.

32768 / 128 = 256 slices

Each slice holds 4 bytes of each of the 32 pages

256 * 4 = 1024 bytes

4 rams in total

1024 * 4 = 4096 bytes (the size of each page)

Nowhere during my extensive testing did I see any evidence of palette ram data in the NVRAMs, even though palette ram was banked into CPU addressable space in all tests that I did. This leads me to believe that the palette ram MUST be internal to the CPU package and banking it in merely redirects palette ram reads/writes to the internal CPU palette ram rather than the external srams. This kind of makes sense as palette ram is usually the last thing that tile/sprite data passes through before being output to the edge connector/video connector and because the RGB data is output directly from the TC0090LVC to the edge connector (via 3 transistors/6 resistors) it make sense to have the palette ram internal to the CPU for speed.

Kind of makes me want to get a TC0090LVC decapped to prove that I'm right....

Is this why your crazy palette writing is cooking the board then Ade?

 

[cmonkey]

I think 'cooking the board' is a bit of an overstatement dude! I don't quite think it's cooking the board but I also don't think that the L System is really designed to change all 512 bytes of palette ram every other vblank either. Without having the recommended L System coding guidelines from Taito it's difficult to say what the limitations of writes to palette ram really are. At the end of the day you've seen from the videos in the first post of this thread that the demo DOES work and work perfectly well (albeit only when I piggyback a known good ram with another known good ram). You've also seen from Ben's video that it fails on his board.

I've studied writes to palette ram from many of the other L System games and the majority only write to it once at the end of each level/round, and even then it's usually only 1 or 2 palettes that changes (32 or 64 bytes).

Still doesn't really explain why piggybacking a perfectly good 32Kb sram at IC1 with another perfectly good 32Kb sram clears the artefacts that I was experiencing!

Ah well, it was a proof of concept that I could get 256 colours on screen and it worked. Time to move on and learn lessons from it.

One thing that the above exercise did show me was that you can actually read and write to/from all 32 x 4Kb pages held in the 4 x 32Kb srams. MAME only emulates reads/writes to 12 of those pages (pages 20-31), so my testing has proved inaccuracies in the MAME emulation of L System. None of the released L System games actually DO read/write to/from any of 20 pages that MAME doesn't support, hence that's why all the games work perfectly under MAME, but it's nice to know that there's another 20 x 4Kb of available scratchpad ram there if I need it!

 

[Hurray Banana]

Great that you've confirmed the ram amount ade. its a healthy improvement on the less than 1k that pacman us restricted to.

 

[Robert]

I'll dig out the rom data. I have a horrible habit of butchering one project to start another without backing up first

Any luck finding that data?

 

[Hurray Banana]

I've got some time this afternoon so will sort out and rebuild the couple of projects I did.

 

[Mitchell Gant]

Still doesn't really explain why piggybacking a perfectly good 32Kb sram at IC1 with another perfectly good 32Kb sram clears the artefacts that I was experiencing!

Could be that the hardware is pushing the limits of read or write access times and piggybacking another RAM chip adds enough capacitance to the address, data or control lines to slow down the signals and make it work.

Great work I'm watching with interest, please keep it going!

 

[cmonkey]

Could be that the hardware is pushing the limits of read or write access times and piggybacking another RAM chip adds enough capacitance to the address, data or control lines to slow down the signals and make it work.
Great work I'm watching with interest, please keep it going!

Thanks! I was hoping someone with some electronics knowledge would comment.

I would certainly have believed what you'd said above BEFORE I went delving deep into the heart of the system and all but proved that palette ram must be stored inside the TC00900LVC. After all but proving that I'm no longer 100% convinced though. The palette rotation routine does its work completely in palette ram, CPU registers and rom accesses (for the CPU instructions), at no point does it access main CPU ram or any of the other ram banks. This means if, as I strongly suspect, palette ram is located in the CPU package then the 4 x 32Kb rams wouldn't be read or written during the routine.

I don't know, without knowing more from Taito about the mysterious TC0090LVC it's all a bit of fun and guesswork really! I'm half tempted to send my code to them and ask them why it's not working as expected!

 

[Robert]

I've got some time this afternoon so will sort out and rebuild the couple of projects I did.

I guess nothing was found?

 

[Hurray Banana]

Hi Robert, yeah found some stuff, which I will link up, but these will be just a prelude to a proper more joined up demo or scrolling effects.

I'll upload two simple demos tonight. on my pacman demo thread

 

[cmonkey]

I'm glad this thread got bumped because it gives me an excuse to update it.

I finally figured out what was causing the issues mentioned on the previous pages whereby the demo worked perfectly in MAME and exhibited random artefacts when deployed to real hardware. It turns out that it was uninitialised ram, more specifically uninitialised character definition ram (that's text ram to the man in the street!). If you watch closely you'll see that there are actually no text characters used for the entire duration of the demo (the huge ass scrolly text is done with tiles, not text).

L System is relatively obscure in that character definitions must be copied from rom to character definition ram at boot time. The CPU then looks in character definition ram for the correct characters when you want to print text to screen. Because of the fact that I wasn't using text in the demo I figured I'd be OK to simply skip the zeroing of character definition ram and copying of character definitions from rom to ram. Oh how wrong I was!!!

The artefacts shown on the video are a direct result of failing to zero the character definition ram at boot time. This is obviously not a problem when developing in MAME as MAME automatically zeroes all ram regions when you launch a game. The cold, harsh reality of life is that uninitialised SRAM contents can (and do!) contain values other than zero. As the text layer on L System is displayed on top of all other layers the hardware was merely displaying the contents of the character definition ram for the character at index 0, and this varied from my board to Ben's board, as SRAMs from different manufacturers obviously contain different values (if left uninitialised) at boot.

A simple fix later (i.e. initialising the character definition ram to zero) and the demo works perfectly on my board, with zero artefacts and without the need for piggybacking a good SRAM on top of another good SRAM (I still can't explain why that caused the artefacts to clear, maybe the uninitialised contents of the piggybacked SRAM are zero whereas the uninitialised contents of the soldered SRAM are non-zero?)

So, the lesson of the day is, ALWAYS INITIALISE SRAM, EVEN IF YOU'RE NOT PLANNING ON USING THAT SRAM!

New code binary attached

https://www.ukvac.com/forum/data/uploads/1497/ic10_256_demo_FIXED.zip

 

[Sprint]

Here's my guess as to why piggy backed SRAM might have helped.

The piggy backed SRAMs would have initialised randomly, but perhaps with more "0"'s than "1"'s. When reading the SRAMs out, this means that the different values would have been written out to the same bus lines at the same time.

It depends a little on the output buffer of the devices, but if they have a lower resistance when sinking to ground, than when sourcing to +5V, then the ground drive will "win" and the line will appear to be logic low.

This is not true of all logic types, but certainly all TTL variants exhibit this behaviour and NMOS tech will as well. Any open-collector logic would also do this (although I doubt this is the case here). CMOS, on the other hand, would be balanced and would not exhibit this behaviour, and most SRAMs tend to be CMOS...

Anyway, assuming a low output does sink current better than a high output sources it, this means the "truth" table would look something like this:

SRAM A "0", SRAM B "0", will look like 0

SRAM A "1", SRAM B "0", will look like 0

SRAM A "0", SRAM B "1", will look like 0

SRAM A "1", SRAM B "1", will look like 1

But if the probability of initialising to 0 is higher, then there could be relatively few bits in the memory that end up looking like "1"s.

One thing to note though, if you have SRAMs driving different voltage levels into a short circuit, you will get a big current flow. I'd be surprised if the SRAMs weren't getting a little warm to touch! There would certainly be a risk of smoking a chip this way, depending on the duty cycle of the access time (i.e. whether it has a chance to cool down between accesses). This would also be mitigated to some degree if most bits reset to 0.

Good tip on initialising memory though. Much hair has been pulled out over that little issue

 

[Hurray Banana]

Glad you got that sorted Ade.

Maybe the Mame modules that defines Ram areas should fill the area with random junk, like python does when you declare data structures.

Obviously this only matters to homebrew coders.

 

[Robert]

@cmonkey: Thanks for the update. I'll put it into HBMAME and throw out the old one.

You could have compiled a debug build of MAME and tried that, I think it fills memory with random stuff instead of zero, if not otherwise specified.

@HurrayBanana: I look forward to the demos in your pacman thread.
Robert2015-09-23 03:59:06

 

[cmonkey]

You could have compiled a debug build of MAME and tried that, I think it fills memory with random stuff instead of zero, if not otherwise specified.

Can you elaborate on that please Robert as it would be hugely useful to me to have ram filled with random values rather than initialise to zero. It would make testing of my code in MAME more resemble that same code running on real hardware. I've looked through the MAME source pretty extensively and can't find anywhere where you can fill RAM regions with random values with a debug build. You can fill ROM regions with random values in a debug build, but not RAM regions. Is there something that I've missed somewhere?

From romload.c

#ifdef MAME_DEBUG
/* if we're debugging, fill region with random data to catch errors */
else
fill_random(romdata->machine(), romdata->region->base(), romdata->region->bytes());
#endif