hoglet67 / atombusmon Goto Github PK

This may cause us to overflow 16KB again

Do this in a way that can be disabled in the godil_250 builds, using a flag in the Makefile.

I have a system with (6) 64k rom chips and (2) 64k ram chips an a "novel" custom MMU and messaging structure that allows paging the entire system memory map in/out. When disassembling it is difficult to know what chip I am currently working with.

Is there a way to add an instruction like mbu (memory bank used) and have it just sample 8 spare pins and report a bitfield of the pin statuses? It would be awesome to integrate into the system so (2)C2B2 : LDA #29 and you know mem2 is active.

Maybe I look wring,but I can not find an index of wikipages that are here. I am going to build a ICE-Z80 with a 500. What I found until now is:
https://github.com/hoglet67/AtomBusMon/wiki HOME
https://github.com/hoglet67/AtomBusMon/wiki/Compiling-firmware
https://github.com/hoglet67/AtomBusMon/wiki/Firmware-Overview
https://github.com/hoglet67/AtomBusMon/wiki/Toolchain
https://github.com/hoglet67/AtomBusMon/wiki/ICE-T80
Is there more available?

And something else:
I like the adapter board that joeyoravec made, see page 21 of stardot.org. Tobe able to contact him, you need to register as a member on stardot.org. The registration has to be approved. I guess there is nobody homeanymore because the registrattion does not proceed, so I can not contact joeyoravec.
Any suggestion on this? His adapterboard looks cool

I have a piece of test equipment running a z80 I want to repurpose. To figure out how to interface with its hardware I need to disassemble and map IO.

I tried traditional methods like IDA but the manufacture specifically chunked up the asm with random jumps and then filled the inter-spaces with valid opcodes to obfuscate things. To make it even harder there is a PAL that logs IO writes and does a CRC or something to give a jump offset as well.

Does the disassembly instruction run the memory through the processor core or is it just opcode conversion from raw memory? Would single-stepping disassembly be a true view of what the processor is doing?

Dave,
I'd like a PCB for the (Z80) adapter board. Do you still have these?

Thanks,
Scott

To force the CPU to start executing at a given location.

There are a couple of approaches to consider:

1. Extend the CPU core to support register writing on the debug interface (T80 already has this)
2. Force a JMP xxxx command onto the CPU core data bus

The following commands need attention:

• fill
• crc
• test
• trace
• wrm/wri

Please, build a new version firmware for GODIL500.

I restored my Godil after burnout of one pin due to improper insertion into the connector. replacement of the 74CB3T16211 buffer fixed the problem.

Fill command, fill in one byte more than necessary
On Z80

fill 4000 40ff ff
but 4100 filling too

I noticed that when I was testing some scripts via the serial port for batch testing, that if the ICE is on a powered down UUT, that these two command will run (which is good), but they are about 100-200x slower. A 'test 0000 0FFF -1' takes about 1 second in place of my 6502B CPU, but when I have the ICE on my PC via USB with no UUT or the UUT is turned off, it will take over 3 minutes to return.

Any chance that if the ICE is in missing clock mode if these can auto clock or just return a zero result in order to complete in a timely manner?

Currently this is implemented only in the 6809

eepizza on ebay no longer sells the mini board it seems. Is the Mojo V3 a viable alternative?

https://alchitry.com/products/mojo-v3

In several hardware configurations, either the 6502,6809 or Z-80 are a slave processor. In those situations it is common that if the CPU stops responding to the master CPU, that the Master CPU will reset the slave to try and get it back on track. When doing commands like 'test' or even just interrupting the processor on the ICE, it will force a reset to happen.

I was wondering if it was possible to mask the RESET signal into the CPU core so that it is possible to debug via ICE and ignore any RESETs sent via the input pin? This would be similar to the masking if the IRQ and NMI (and FIRQ on 6809) inputs but would expand to the RESET. I looked at the code and it looks like there may be a 0x7 limit on the mask definitions which would make this more difficult on the 6809?

It's only hit ~50% of the time (on pressing reset)

Setting at 0001 is 100% reliable.

Noticed this before (with Ed) so not a new issue.

My secondary use case for an ICE is to troubleshoot new code that is being published and tested on the target hardware. I use MAME with an appropriate hardware driver to do virtual testing first, and then, by burning new ROM's I can test on the target hardware. The ICE allows me to debug that code nicely. However the step of erasing and reprogramming 4-6 ROM's each time takes about 30 minutes and any small change in the compiled code may change all of them.

If I were to remove all the Physical ROM's from the target hardware, which would leave the data bus un-driven. Is there a possibility for the ICE to have a binary file equivalent (stored on the PC or in FPGA memory?) that would effectively 'replace' the CODE being read? In theory it could be the entire 64K memory space but in practice it would be typically a smaller subset of that space (16-32K)

This is eerily similar to the 6502 EXEC command you implemented and my guess is that due to the core structure, having the ability to intercept the Data Bus like this is problematic on the current cores?

I would be willing to help code this under advisement. I do have hardware, assembly and C# skills, just not VHDL or much C proper, but Im a learner!

Hi Dave... Im writing Window's based software that will do a bunch of automation in regards to scripting out a 'hardware test map' for a user defined platforms using your ICE projects. So if you envision the steps required to maybe do the following..

Test RAM from 0x000-01FF - maybe test all patterns
SET RAM Page 1(via memory write to 0x1740 of 0)
Test RAM from 0x0200-07FF
SET RAM Page 1 (via memory write to 0x1740 of 1)
Test RAM from 0x0200-07FF
Test RAM from 0x0800-09FF
Test Paged ROM similar to above (8 pages from 0x2000-0x3FFF) - match a preconfigured checksum
Test RAM from 0x4000-4FFF
Test ROM from 0x5000-5FFF - match a preconfigured checksum
Test Paged ROM similar to above (4 pages from 0x6000-7FFF) - match a preconfigured checksum
Test ROM from 0x8000-BFFF - match a preconfigured checksum
Test ROM from 0xC000-FFFF - match a preconfigured checksum

I'm batching a straight PASS/FAIL and the basic concept is that both the commands and return values need to be easy to read from a programmatic standpoint. It certainly isn't the end of world to parse this out, but it certainly will be error prone over time.

So for example... right now, upon start, I need to run the 'help' command to identify connectivity and get the CPU Identifier string (and then ignore all the rest). Or if I want to read the Version of the firmware, I need to run 'help' and then parse out through string regex the version number in the middle of the response.

The next example which is simpler, but still illustrates a point is the 'crc' command which I just need to skip out the leading 'crc: ' from the 4 digit hex value.

With all of that, I wanted to ask a couple questions to make sure that if Im doing work, that Im in line with your vision because I am happy to contribute to your main Dev branch if you find it valuable.

1. I suspect that many of the 'programmatic' versions of commands will be very similar, just less wordy. For example I have in my branch and 'id' command that simply returns the ICE Identifier 'ICE6809' and another command 'ver' just returns '0.998' and for crc it returns just 'FFFF' or whatever. as I look at your code, this will become problematic eventually because there will be essentially double the commands potentially. Perhaps it is more worthwhile to make a command to set an internal flag that is the opposite of verbose and more like 'concise'... it would be false by default unless set, and then once 'concise' is set, then all commands would return the shorter version. Even with 'concise', I would probably still need an 'id' and 'ver' commands.
2. Another option since this is programmatic only, is to make a super flexible command that just takes parameters... so maybe like 'xxx' that takes a first parameter from 0-i which actually maps to a whole different command structure. so 'x 0' might return the ICE Identifier, 'x 1' would return the version number, 'x 2 0000 01FFF' would return a CSUM from 0000-1FFF etc. Perhaps that actually makes more sense?
3. Maybe you don't even want to have this functionality in your branch and that is good too, I just want to know what you prefer because I can see pros and cons for both directions. Plus, if you don't want this in your branch, I won't bother with pull requests to you.

Thoughts?

See discussion in:
#1

Thank you for a very interesting project!
I want to ask you whether you can add support for CPU 1801BM1 in your project.
There is a working model of it https://github.com/1801BM1/cpu11/blob/master/readme.md with configuration for Xilinx devboard
I think that you can transfer it to the GODIL board quickly.
I understand that adding debugging tools is much more difficult. But perhaps gradually it can be done by joint efforts.
If you are interested, I can send you the original of this CPU.

There is a suggestion, add commands for load and save the region of memory through the transmission of a binary stream in the terminal program. e.g. Realterm.