Posted By
crock
on 2012-01-22
10:01:30
 |  First Beta Release of Diag264 (0.2B)
 Finally, after what seems like a very long time I have the first beta release of Diag264, the diagnostic ROM and test harness for the Plus/4, Commodore 16, Commodore 116 and other 264 series machines.
You can find a complete description of how it works and how to build the harness here. Cartridge and kernal ROM images for both NTSC and PAL versions of Diag264 can be downloaded from here:
If you would like me to burn an EPROM for you, let me know which flavour you want and I will gladly do so for the cost of 5 CHF plus postage. At the time of writing this post, that's about 3 GBP, 4 EUR, 5 USD and 1250 HUF. If you would like me to modify an existing cartridge for you, you can mail it to me and I will do so for an additional 15 CHF, depending on the demand.
Please feed back comments, suggestions and questions you might have, either to this forum or to the email in the document.
|
|
Posted By
crock
on 2012-01-22
10:01:30
| Re: First Beta Release of Diag264 (0.2B)
[continued]
If you wish to experiment and get a feel for the tool, all of the versions will work in Vice and Yape, although you will occasionally get bad ROM checksums in Yape unless you disable the "Patch Kernal LOAD vector" in the advanced options.
Also, in both Vice and Yape, the tests that check for the presence of a particular register or ROM by polling for a stable value will report as bad instead of skip, as the data lines do not 'float' in an emulator.
Have fun,
Rob (aka Crock)
20120122
|
|
Posted By
Gaia
on 2012-01-22
18:02:41
| Re: First Beta Release of Diag264 (0.2B)
Great work, Rob! And a really humble price-tag, too!
Sorry for being lazy, but how (what) do you check the serial and the user ports? In emulators it reports a failure but these should not float (that much...  ).
|
|
Posted By
crock
on 2012-01-22
18:59:18
| Re: First Beta Release of Diag264 (0.2B)
I am assuming that your software implementation of the CPU models the fact that the CLK and DATA lines are read/write, and that setting CLK/DATA out high holds CLK/DATA in low, as it's buffered through an inverter on the MB, right?
The ATN line is only an output, so is not internally connected to any read line. To test ATNm the serial port loopback connector sends ATN back into the CLK input, so this step will fail on an emulator.
WRT to the user port, if you run this on a real C16, it will skip the test as it writes a sequence of values to $FD10 which will not be held as there is no register to hold them. You tend to get somewhat random values back, I assume from capacitance on the data lines, maybe as an artifact of the last instruction read?
The fact that YAPE shows this as a fail makes me think that even when you're emulating a C16, the 6529 is still there and thus storing the value. It then fails because the loopback between P4 and P0 is not present, hence a status of $10.
rob
|
|
Posted By
Gaia
on 2012-01-23
02:22:11
| Re: First Beta Release of Diag264 (0.2B)
Thanks. Well, from what you write I think the serial check should not fail on an emulator if we enabled true 1541 or 1581 emulation otherwise that would mean no drive emulation at all. Another possibility that SHOULD fail (but I'm sorta speculating) would have been timing the delay of the signal response that comes in on CLK when the ATN bit is set which is quite "analogue", while it happens immediately on emulators.
As for the user port thingie, I must check that tonight. The random data what you get is actually the bytes read/written in the previous clock cycle from the data bus. That is why you get so frequent $FE values when watching an unconnected memory area somewhere at $FExx in monitor for example.
|
|
Posted By
crock
on 2012-01-23
04:03:51
| Re: First Beta Release of Diag264 (0.2B)
Right. Most of the serial port tests do work with true drive emulation. It only fails on the ATN->CLK step. I did wonder whether signal delays would be a factor, but having run the tests on around 20 different peices of 264 hardware, including some very early pre-production boards, I never noticed any delay that would have been timeable in code.
|
|
Posted By
Gaia
on 2012-01-23
16:25:51
| Re: First Beta Release of Diag264 (0.2B)
Ah, stupid of me. I have mixed up the ATN low -> DATA high response, but here you were talking about something completely different (CLK, dough!). I've not read your page until now
|
|
Posted By
siz
on 2012-01-24
01:56:31
| Re: First Beta Release of Diag264 (0.2B)
I'm not sure but this ATN->CLOCK loopback would require the emulation of the dongle, wouldn't it?
I've just looked at $fd10 6529 in YAPE: I think that $fd00-$fd0f always reports $00 and $fd10-$fd1f always reports the written value (except when using parallel 1541 emulation).
So it seems that these emulations are not toggled by selecting the machine type, they never float.
(I've used my own monitor program to check as that contains an expansion are check and uses this floating to detect if anything responses for reading a selected address)
|
|
Posted By
crock
on 2012-01-24
03:40:19
| Re: First Beta Release of Diag264 (0.2B)
Yes, it would. While it would have been very useful for me to be able to arbitrarily connect signals to each other during development, I am not requesting this as a feature. But if it was easy.... 
I can't imagine much other software requires the databus to emulate the contents of the previous cycle unless it's perhaps for some quirky protection scheme. Again, it would have been convenient for me but I do not think it's worth trying to emulate it. Plus you can't guaranteee that the databus would always contain the contents of the previous cycle. If that was the case, I would have always seen the same 'false' checksums when checking a missing ROM. There's definitely some transients on real hardware.
Rob
|
|
Posted By
Gaia
on 2012-01-24
17:38:06
| Re: First Beta Release of Diag264 (0.2B)
The transients (and the floating bus checksums) could be checked with a cycle exact, stable raster or (I'm speculating a bit here) writing 1 to the TED off bit (no DMA, single clock, etc.).
siz: the $FD10 PIO should never float should it? I am not so up-to-date anymore
|
|
Posted By
siz
on 2012-01-25
04:51:47
| Re: First Beta Release of Diag264 (0.2B)
You made me uncertain: I thought that only plus/4 contains a PIO at $fd10. I've to check the schematics. Or better: the pictures I took last time when I've disassembled my C116.
Well, I have a nice shot of the C116 mainboard: it has only one PIO for the keyboard selection. I've checked the schematics in the Zimmers archive and found (though crock's recent thread on CBM Hackers list helped a bit) that on the C116 there is a 74LS125 that gates the casette sense for the $fd10 chip select but it's connected to D2 only so all the other data lines are floating in those machines. I'll extract my detect routine from the monitor source (as it's burned in an EPROM and that is in my plus/4 rather than on a cartridge) and will try it on the C116 today.
Edit: I made the expansion area scanner and ran it on a C116 and a plus/4. The + symbol means that a stable result is read for at least 255 reads and - means (of course) the opposite).
Edit2: I've uploaded the scanner here in case someone wants to try it out.
|
|
Posted By
crock
on 2012-01-25
08:10:33
| Re: First Beta Release of Diag264 (0.2B)
The transients (and the floating bus checksums) could be checked with a cycle exact, stable raster or (I'm speculating a bit here) writing 1 to the TED off bit (no DMA, single clock, etc.).
That's stretches the boundaries of my understanding Gaia, could you explain the theory of that? Is there any practical application of turning the TED off?
I made the expansion area scanner and ran it on a C116 and a plus/4. The + symbol means that a stable result is read for at least 255 reads and - means (of course) the opposite).
Interesting. As expected, I only see stable values at FD00, FD10 and FD30 on real iron. The area from FF20 to FF3D is normal ROM/RAM. One of the things I found while developing Diag264 was that reading the 2 'fake' registers at FF3E and FF3F return the contents of ROM if ROM is visible but will never return the contents of RAM - I think you always see 00 on real hardware.
|
|
Posted By
siz
on 2012-01-25
06:59:19
| Re: First Beta Release of Diag264 (0.2B)
@crock: and what about ACIA at $fd00 on a plus/4? Or have you removed yours? Mine is shown in my screenshot.
And you are right about the $ff20-$ff3d area: I forgot that I've used to use that are in some of my codes to store data. But one of the emulators (probably VICE) does not support that area as system RAM so I had to relocate them to test other features (for example 1571 drive compatibility). :/
So that was the reason why my original routine scanned up to $feff only. I forgot it completely.
Offtopic: I've always wondered why is color $6e called as light blue. I've always seen it as some light purple. Comparing the two screenshots (taken by the same USB Video capture device, both within 10 minutes) the border on the C116 is more blueish. :)
|
|
Posted By
crock
on 2012-01-25
08:19:31
| Re: First Beta Release of Diag264 (0.2B)
@siz - a typo, I edited my response - I was being distracted by a telephone conference in the background. I really shoudn't work while I'm playing.
I raised a bug a few weeks ago with the Vice team concerning FF3E & FF3F. I think the handling of FF20 -> FF3D is now corrct. The TED mode tests in DIag64 also highlighted a few other issues in Vice2.3 which they fixed pretty quickly.
How did you capture those images?
|
|
Posted By
siz
on 2012-01-25
08:58:54
| Re: First Beta Release of Diag264 (0.2B)
@crock: I've a very cheap USB Video grabber from eBay (one like this: http://www.ebay.co.uk/itm/USB-2-0-Audio-Video-Grabber-Card-DVD-TV-HD-Capture-/200644972736 ). I use it to watch the screen of my home computers on my laptop (using VirtualDub capture mode). To find a driver for Win7 x64 was a bit painful but finally accomplished.
However the audio input is a crap (it reports itself as a microphone and adjusts preamplifing according to that fact and distorts the sound) but the laptop's builit-in line input is perfectly usable).
|
|
Posted By
Gaia
on 2012-01-25
15:09:44
| ACIARe: First Beta Release of Diag264 (0.2B)
@siz: this is amazing, I wouldn't have thought that there was a significant difference other than the ACIA. I mean I may have known earlier about the lack of a PIO in the C16 but totally forgotten by now. So we have one more way to detect the machine type. I wonder how the C116 looks since that was probably the earliest spinoff of the 264 line and the C16 the last one.
@crock: well, there is not much use really, other than perhaps testing. There are no interrupts, no keyboard, no DMA, only single clock and 5 RAM refresh cycles per line. Now as I write this I realize that even with the TED turned off you would get different results due to the RAM refresh. The 8 bit counter is incremented by one on each access and the area $FFxx is read. So that's what makes reading open address space look totally random (though it's predictable). Read here:
http://plus4world.powweb.com/ma.php?maid=154&h=ram%20refresh
And here is some more black magic on bus accesses:
http://plus4world.powweb.com/ma.php?maid=23
EDIT: well, from here it appears that the C116 had the 74LS125, too: link
|
|
Posted By
Litwr
on 2012-01-26
03:10:33
| Re: First Beta Release of Diag264 (0.2B)
BTW I've just tested this firmware with Linux Plus4emu and DOS Plus4Forever?. Both emulators successfully passed all tests which didn't involve loopbacks. IMHO delay at the end of testing loop is a bit too short. ;-)
|
|
Posted By
crock
on 2012-01-26
17:00:50
| Re: First Beta Release of Diag264 (0.2B)
@gaia: I have been staring at the schematics of the C116 compared to the C16 and I can't see any way to distinguish between them.
@litwr: noted. I will increase the delay for the next release.
|
|
