PI/Arduino Processor Emulator

[GadgetFreak]

If you use a fly lead to connect to the master clock on the board and detect an edge from that to synchronize the IC pin sampling you should be able to get a reliable sample that's always stable across all IC's and thus avoid the transition instability.

The idea would be to detect the clock edge then read in all of the byte-ports then process them later to minimize the delay between clock edge to sample point.

Just wondering if you have implemented this method for the ADT mode or did you work out an alternative to get more reliable results?

Do you have any plans to implement a TTL detection mode? There are certainly a few boards with scratched off chip numbers it would be handy for

Also, do you have any long term plans for 68K support or will it be purely limited to 8 bit cpu's?

Lastly, I have seen several comments in the thread about the limited power of the Arduino board you are using. Am curious if you ever gave the Arduino Due a look, I have used it on a couple of projects and found the extra clock speed (84 Mhz) handy. Main differences I can see are 3.3v rather 5v tolerance and only 12 analogue inputs rather than 16.

Is there currently a waiting list or have you caught up ?

 

[andrewsm]

Hi,
I have been busy with other stuff recently but not ruled out the ADT method Paul has suggested. I have another idea which I can try when I get a minute and that should also limit the spurious fails that occur occasionally.

TTL detection may be possible, I always say nothing is impossible, but might need a bit more programming to do this,

The 68000 is on the cards. I will start work on this probably next month once I have finallised the emulator and also fix a few more boards for guys.

I have looked at the Due. There are some hardware issues with it as instead of 5V logic its 3.3V. This will mean its not a drop in replacement just yet. It will be the natural progression but Im thinking it may end up in a new model tester eventually unless I figure out a method of shoe horning it it.

Waiting list?? Can you remind me mate as my memory is a little fried these days lol

 

[GadgetFreak]

I thought there may be a waiting list but sounds like there isn't so all good.

On the 3.3v / 5v subject, there are a few bi-directional level translator chips but most don't allow much current.

http://www.mouser.co.uk/new/Texas-Instruments/ti-txb0108/

http://www.digikey.com/product-detail/en/GTL2000DGG,112/568-4223-5-ND/1156316

Adafruit uses the first one it this board http://www.adafruit.com/product/395

Sprkfun does a board as well http://www.sparkfun.com/products/12009

I did also find this post from a guy who designed a Due shield to convert all the lines....

http://forum.arduino.cc/index.php?topic=172362.msg1292907#msg1292907

Anyway, this was all just for your future reference if you need to go the Due route

 

[andrewsm]

Thanks for the info, I will look into this later on. As said it will only be on a future tester as the current ones are doing well and have loads of life left in them. Not planning to do a new one just yet until the time comes that they cant handle additional tasks.

Drop me a PM as I dont have any waiting list on the testers. They are built to order and if you would like one get in touch and I will run though the options.

Thanks

Mark

 

[PaulSwan]

The trouble with level shifting is the need to control per pin the direction & output enable making them awkward to use in the general case versus full dedicated HW per CPU.

On the 68000 front, using SW pin drive on my HW is marginal for GX400, Twin16 & GX945 platforms because they all use synchronous bus cycle completions. Writes are OK, but for reads you'd need to external latch based on DTACK and the CLK edge per the 68K data sheet to hit it perfectly. On top of that, the VPA 6800 mode uses different bus cycles (none of the Konami platforms usually use that cycle thankfully).

The good thing about 68K is that clip over works fine with Bus Request - no need to remove the CPU and thus RUN UUT works if the CPU is good

Paul.

 

[andrewsm]

Thanks for that Paul. Yes the level shifting is a pain and yes you are correct in that it needs to be bidirectional. Its a challenge but one for a rainly day.

I have not looked much at the 68000 yet if Im honest so once I do, maybe you can give me some pointers since you have already spent some time on it. I guess the bus request will work as a clip over as long as its not tied high by too small a value resistor. If so then the drive for the tester pin would need to be increased since it has to go low to enable.

 

[GadgetFreak]

The chips I linked are bi-directional unlike the 74ls245's. The only down side is you can't sink much current at all and possibly their speed.

Of course the other possibility is to use one of the excellent Teensy boards. I have used a lot of 3.2's for led work but they were 3.3v as well. However the new Teensy 3.5 is 5v tolerant on all its digital pins and is clocked at 120Mhz. They can also be programmed with the same Arduino development system.

http://www.pjrc.com/store/teensy35.html

http://www.pjrc.com/teensy/pinout.html

GadgetFreak2017-02-23 22:58:58

 

[PaulSwan]

Re: 68000 bus request - yes, on GX400 I needed to cut the track on the PCB and fit my own pull-up as it was tied directly to VCC. On Twin16 & GX945 Konami fixed it and used a pull-up resistor so all was good there.

Re: Teensy - alas, not enough IO pins - need to have at least 40, preferably 48, more to drive an LCD/Keypad.

Thanks,

Paul.

 

[GadgetFreak]

Think you might be thinking about the Teensy 3.2, the 3.5 version has 58 digital pins and all are 5v tolerant.

 

[PaulSwan]

Hmm, the 3.5 does look interesting...

 

[andrewsm]

Agree with the 3.5. Multiplexing might be a solution.

 

[Arcadenut]

Been watching your videos. A fantastic tool!

Does it support the 6809?

I'm ready to buy one...

 

[andrewsm]

Thanks mate, just sent you a PM. I will be doing more videos very soon, just been hectic at work plus had some technical issues with the emulator. Now fixed so going to do some very interesting videos which show off its capability.

 

[Hurray Banana]

I like very interesting videos

 

[Arcadenut]

Thanks mate, just sent you a PM. I will be doing more videos very soon, just been hectic at work plus had some technical issues with the emulator. Now fixed so going to do some very interesting videos which show off its capability.

Excellent, can't wait for the new videos.

 

[andrewsm]

Hey guys,

After a far too long delay, I have now got my trusty phone out and started some videos of the new emulator in action. I say new as the original one was a little too unstable for my liking. As I like to make robust solid bits of kit, I re-designed it and well the results are pretty good even though I say it myself.

Take a look and see what you think.

Thanks

Mark

 

[smarty]

Really interesting to see how you've progressed with this Mark. Impressive stuff.

Love the home dev side of things, 'simply' running your own code on an arcade pcb.

There are a few games which have 'test' roms available, I take it you could remove the program ROMs from the board and load the test rom via the emulator, saving having to burn roms and fit them into the boards?

Looking forward to getting the pods and emulator.

smarty2017-04-18 19:43:24

 

[andrewsm]

Hey dont know how I missed this lol.

So the emulator will allow you to load your own code or a game code into its RAM then run it as ROM on any Z80 board. To get the game code or a test program from the eproms there are various ways this can be done.

1) copy the code from the eprom via minipro etc into a BIN file and then load that into the tester

2) Plug the eprom into the board under question and assuming it will read OK, use the emulator to read the code directly from the board using the Z80 socket.

3) Use the up coming eprom programmer for the tester to copy the code again.

Basically the file needs to be a BIN file so once thats done, the emulator can be loaded with it and run as normal. No software roms need to be on the board to do this. You could also write your own test roms using the emulator and store them as BIN files.

Hope this helps.

 

[Arcadenut]

2) Plug the eprom into the board under question and assuming it will read OK, use the emulator to read the code directly from the board using the Z80 socket.

Does this mean it will be able to bypass the EPROM's on the board without having to remove them? If so, that's great as it will make it easier to test.

 

[andrewsm]

yes when the emulator is plugged in you can select if the onboard emulator ram (32K) is enabled or not. If its not enabled then the games ROMS will read and run as normal. If the RAM is enabled in whatever block size, then that block of ROM will be disabled and the emulator RAM read instead. If for example 16K of emulator RAM is enabled, then all the say Galaxian roms will be disabled and your own code can be run instead using the ram. Disable the ram and the Galaxian roms will then be as normal.

Hope all that makes sense. The ram enable is selected by a dip switch and this can be flipped with power on or off. Also the ram is fully battery backed up so again once loaded with code, power can be flipped on or off without any corruption.

I have a bootleg galaxian board with no roms on board apart from the two graphics ones. I use this board as test board so when plugged into the emulator, I can load any compatible game code into in and run it as normal. I have used it on quite a few boards now and all behave fine.

The tester also has a command which can transpose address ranges within the code. So for example if you want to try and make pacman run on galaxian, you can enter a command to search for all addresses that use the video ram address range and convert them to another area of ram instead.

andrewsm2017-05-03 23:07:05