Arduino In-Circuit Tester: Build Project

[Judder]

BTW meant to share this with the thread a while ago, but I ported the build on to Atom and Platform.IO, which is a much nicer build environment that the Arduino standard one

I also added in all of Dave's Williams test code that was on his branch - it's here if anyone wants to have a play

https://github.com/Judder/arduino-mega-ict-atom

Judder2018-10-28 18:43:32

 

[Judder]

Also just to update I've added in Phil's (Nes4Life) games to the Platformio.org build above - you can select them with #ifdef conditions like all the other games just to save on memory

https://github.com/Judder/arduino-mega-ict-atom/tree/master/libraries

 

[Nes4life]

Thanks @Judder! Nice to see it available for others to use.

 

[Judder]

Thanks @Judder! Nice to see it available for others to use.

Pleasure and mega thanks to you for sharing

 

[Purity]

I'm trying to see if I can extend the RAM testing in the System 2 tests that are on the Github

What I can see in the CSystem2BaseGame.cpp is

{NO_BANK_SWITCH, 0x00000000, 0x00000FFE, 0xFF, "c7K", "Prog L"}, // Program RAM 6116, Lo
{NO_BANK_SWITCH, 0x00000001, 0x00000FFF, 0xFF, "c7P", "Prog H"}, // Program RAM 6116, Hi
{CSystem2BaseGame:nBankSwitchVRAM0, 0x03002000, 0x03003FFF, 0xFFFF, "v??", "V.Ram "}, // Video RAM, 16-bit VSYNC

Looking at the Mame driver I think this covers the majority of the RAM:

https://github.com/mamedev/mame/blob/master/src/mame/drivers/atarisy2.cpp

0000-0FFF Program RAM

2000-37FF Alphanumerics RAM

3800-3FFF Motion object RAM (bank 0, 256 entries x 4 words)

2000-3FFF Playfield RAM (banks 2 & 3, 128x64 tiles)

Maybe not the Playfield Ram?

It would be great to also add in the RAM between 1000 and 11FF for the Palette ram

Is it just a case of adding in:

{NO_BANK_SWITCH, 0x03001000, 0x030011FF, 0xFFF, "P??", "Palette.Ram "}, // Palette RAM

Or is it more complicated than that?

Is the Playfield Ram on Banks 2 and 3 covered?

Any thoughts would be appreciated

 

[Purity]

Anyone? Is Paul still around? I noticed his website is no longer available

I think I'm right with the ram. Only bank 0 is covered so there is no playfield ram testing. Only bank 0 is defined and I'm not really sure how to add in support for banks 2 and 3

I think the pallette ram could possibly be added in as this does not use bank switching

There is also no rom testing on the video board :-(

Purity2018-11-30 10:19:46

 

[Purity]

Something else I'm really baffled by is how the roms have different starting points compared to Mame. Any ideas?

If I look at Pauls ssprint example, he has the following defined:

7L - 0x00008000, 0x4000, 0xee312027

7N - 0x00008001, 0x4000, 0x2ef15354

6F - 0x00800000, 0x8000, 0xed1d6205

6N - 0x00800001, 0x8000, 0xaecaa2bf

6K - 0x00A00000, 0x8000, 0xde6c4db9

6R - 0x00A00001, 0x8000, 0xaff23b5a

6L - 0x00B00000, 0x8000, 0x92f5392c

6S - 0x00B00001, 0x8000, 0x0381f362

When I look in the Mame source I see the following:

7L - 0x008000, 0x004000, CRC(ee312027)

7N - 0x008001, 0x004000, CRC(2ef15354)

6F - 0x010000, 0x008000, CRC(ed1d6205)

6N - 0x010001, 0x008000, CRC(aecaa2bf)

6K - 0x050000, 0x008000, CRC(de6c4db9)

6R - 0x050001, 0x008000, CRC(aff23b5a)

6L - 0x070000, 0x008000, CRC(92f5392c)

6S - 0x070001, 0x008000, CRC(0381f362)

Why is the starting point of roms 6F-6S different on Paul's code? Any ideas?

Why is 6F not:

6F - 0x010000, 0x8000, 0xed1d6205

in the arduino code?

Clearly I'm missing something or have not understood correctly

Purity2018-11-30 10:35:48

 

[Judder]

Hi Ben

I've not heard from Paul recently but I'm around so can help you with this (hopefully!)

Let me have a read over the weekend and I'll post up some thoughts to your questions and try out some things too

Alex

 

[Purity]

Hi Ben

I've not heard from Paul recently but I'm around so can help you with this (hopefully!)

Let me have a read over the weekend and I'll post up some thoughts to your questions and try out some things too

Alex

Thanks Alex

Any suggestions would be welcome. It would be good to add Paperboy support and extended support to the T11 code

 

[Purity]

I would imagine the Paperboy R3 CPU rom code would be:

{NO_BANK_SWITCH, 0x00008000, 0x4000, s_romData2n_c7L, 0x4024bb9b, "c7L"}, // Fixed Prog. Mem Lo {NO_BANK_SWITCH, 0x00008001, 0x4000, s_romData2n_c7N, 0x0260901a, "c7N"}, // Fixed Prog. Mem Hi
{NO_BANK_SWITCH, 0x00010000, 0x4000, s_romData2n_c6F, 0x3fea86ac, "c6F"}, // Paged Prog. Mem Lo
{NO_BANK_SWITCH, 0x00010001, 0x4000, s_romData2n_c6N, 0x711b17ba, "c6N"}, // Paged Prog. Mem Hi
{NO_BANK_SWITCH, 0x00030000, 0x4000, s_romData2n_c6J, 0xa754b12d, "c6J"}, // Paged Prog. Mem Hi
{NO_BANK_SWITCH, 0x00030001, 0x4000, s_romData2n_c6P, 0x89a1ff9c, "c6P"}, // Paged Prog. Mem Hi
{NO_BANK_SWITCH, 0x00050000, 0x4000, s_romData2n_c6K, 0x290bb034, "c6K"}, // Paged Prog. Mem Lo {NO_BANK_SWITCH, 0x00050001, 0x4000, s_romData2n_c6R, 0x826993de, "c6R"}, // Paged Prog. Mem Hi
{NO_BANK_SWITCH, 0x00070000, 0x4000, s_romData2n_c6L, 0x8a754466, "c6L"}, // Paged Prog. Mem Lo
{NO_BANK_SWITCH, 0x00B70001, 0x4000, s_romData2n_c6S, 0x224209f9, "c6S"}, // Paged Prog. Mem Hi

I haven't yet done the interval checks at 01-4000 that is done on the other roms so I'll do that next

Might save someone quite a lot of time

Purity2018-12-01 12:33:49

 

[Purity]

// Base set from MAME (paperboy) - rev3 rom set
// 01 02 04 08 10 20 40 80 100 200 400 800 1000 2000 4000
static const UINT16 s_romData2n_c7L[] = {0x7e,0xdf,0x02,0x00,0x1f,0x1f,0xc0,0xd9,0x86,0xc4,0xfc,0x34,0x1f,0x00}; //rev3 rom
static const UINT16 s_romData2n_c7N[] = {0x01,0x0b,0x80,0xe0,0x0a,0x0a,0x17,0x0a,0x8e,0x03,0xff,0xbc,0x8a,0x00}; //rev3 rom

static const UINT16 s_romData2n_c6F[] = {0x06,0x2c,0x81,0x89,0x54,0x01,0x06,0x91,0x0c,0x03,0x01,0x01,0x01,0xf7); //rev2 rom
static const UINT16 s_romData2n_c6N[] = {0x0e,0x34,0x45,0x86,0x80,0x26,0x06,0x00,0x4c,0x03,0x01,0x01,0x01,0x5f}; //rev2 rom
static const UINT16 s_romData2n_c6J[] = {0x6e,0xc0,0xca,0xae,0x76,0x8e,0x10,0x3e,0x92,0x96,0xfe,0xd6,0x55,0x02}; //rev1 rom
static const UINT16 s_romData2n_c6P[] = {0x7c,0x02,0x02,0x0f,0x0a,0x13,0x7e,0x04,0x08,0x7c,0x7c,0x7c,0x55,0x03}; //rev1 rom
static const UINT16 s_romData2n_c6K[] = {0x01,0x71,0xbf,0x01,0xe9,0x73,0x59,0xf8,0x2b,0x2e,0x05,0xe0,0xd5,0x01}; //rev1 rom
static const UINT16 s_romData2n_c6R[] = {0xe8,0x01,0x00,0xe8,0x00,0x01,0x01,0x7b,0x2e,0x2b,0x85,0x72,0x0a,0xec}; //rev1 rom
static const UINT16 s_romData2n_c6L[] = {0x05,0xc8,0x4a,0x01,0xc8,0x23,0xdc,0x39,0xfc,0x49,0x01,0x48,0x91,0xc0}; //rev2 rom
static const UINT16 s_romData2n_c6S[] = {0xad,0x44,0x4b,0xcc,0x26,0x01,0x05,0x02,0x07,0x00,0x4a,0x49,0x40,0x08}; //rev2 rom

 

[yorkshire_spam]

Is anyone currently supplying the bits and bobs needed to jump on this bandwagon as a kit? Or do I need to source them all myself?

 

[Purity]

Is anyone currently supplying the bits and bobs needed to jump on this bandwagon as a kit? Or do I need to source them all myself?

Judder will probably have some

 

[Judder]

Is anyone currently supplying the bits and bobs needed to jump on this bandwagon as a kit? Or do I need to source them all myself?

Judder will probably have some

Yes - I think I might have a spare set of each - I'll check...

 

[Nes4life]

If someone was really thinking hard they could probably create a script to export a basic implementation for all games (with a supported CPU) from MAME. All the core info is there; just needs to be bridged over. Maybe I'll look at that for kicks. Why keep transposing by hand when we can script it once?! PS: python (so we can use any platform then).
Nes4life2018-12-21 07:44:59

 

[yorkshire_spam]

If someone was really thinking hard they could probably create a script to export a basic implementation for all games (with a supported CPU) from MAME. All the core info is there; just needs to be bridged over. Maybe I'll look at that for kicks. Why keep transposing by hand when we can script it once?! PS: python (so we can use any platform then).

I'd been thinking something along the same lines, although because I'm "old school" I was thinking a Perl script! ;-)

 

[Judder]

If someone was really thinking hard they could probably create a script to export a basic implementation for all games (with a supported CPU) from MAME. All the core info is there; just needs to be bridged over. Maybe I'll look at that for kicks. Why keep transposing by hand when we can script it once?! PS: python (so we can use any platform then).

Hi guys

Took me a while to find the post but BattleZone started something similar over here on this post

http://www.ukvac.com/forum/forum_posts.asp?TID=349525&PID=947569&title=arduino-incircuit-tester-build-project#947569

More text files, than auto-generated code, but should give you a start to look at

One thing to remember, is that the Arduino has such small RAM that you can only have a few games compiled in at the same time

I've been looking at ways to increase the memory in the AT Mega to cope with this but haven't the time bar reading some good links

https://www.rugged-circuits.com/new-products/quadram

http://andybrown.me.uk/2011/08/28/512kb-sram-expansion-for-the-arduino-mega-design/

https://hackaday.io/project/21561-arduino-mega-2560-32kb-ram-shield

The problem is that the pins interfere with the Arcade shield, so we'd need to be clever etc.

 

[yorkshire_spam]

With the memory restriction on the Arduino I wondered about writing a simple interface program (PC/Linux/Mac based) that can send the definitions to the arduino at run time? (Just thinking aloud)

 

[Judder]

BTW I think I'm wrong on my statement above on the Arduino memory

"One thing to remember, is that the Arduino has such small RAM that you can only have a few games compiled in at the same time"

Arduino Mega's come in 128Kb and 256Kb formats, which is what affects the number of game codes we can store at any one time in them

The SRAM that is used by the run time programs, is by default 8Kb (so very small) so that's the bit we could expand and use to our advantage

How about using compression to store all the ROM definitions in the upload file, and then (with expanded memory) unpacking them at run-time to use with every game?

Knowing text based compression, we can probably get all of the game definition files really bzip'd down nicely

Just a thought

The other option is to start optimising the existing code base - there's probably some extra library files we can strip - I'll have a look when I get some time

 

[GadgetFreak]

I've never looked at the code for this but if the game data is predefined in arrays of one kind or another it shouldn't be taking up any ram if it is defined correctly using static & const datatype modifiers.
If this isn't done correctly the startup code for the board will generate a ram based copy from the rom copy at run time thus wasting space if the data is not modified.