Adrian, that is amazing! When I start watching your channel, it was about C64s and multimeter. Now you are at oscilloscope and creating your own diag ROMs. That’s an amazing journey. And your skill in explaining, your easy to listen voice and your success make your channel my must-watch at weekends.
Due to the small size of the .BIN file for the EPROM being just over 1K, you can get away with a better option for an EPROM that does not require an adapter board. A TI TMS2516 EPROM is pin for pin compatible for the stock ROM ICs, are still readily available as NOS and are reasonably priced. Most EPROM programmers have the capability of programming the 2516 without issue. I tested this for proof of concept just this morning on my 48K Model I, and it works just fine. And yes, your ROM does work on a Model I without issue. Mine does have the lowercase mod with the extra piggyback SRAM to get the 8th bit, so it does work on the VRAM test just fine.
Not only excellent, well presented, educational, and thoroughly enjoyable content, but a real service to the retro computing community too! I salute you!
I peeked at the code, some really clever and tricky stuff in there. But the thing that really made it possible VRAM test (without stack or ram) and relocating the stack to VRAM is nothing short of genius.
If the VRAM is directly mapped into the memory space, then it's sort of an obvious thing to do. But this apparently is being tailored to work on machines that _don't_ map the VRAM directly into memory space, and _that_ is genius. One interesting point might have been covered up by Adrian's picture in the corner -- it would have been interesting to see if the last characters on the screen reveal the contents of the stack.
Feature Ideas. Add a second entry point into the ROM so that it can be installed in the ?third? ROM socket (is it compatible?). Then you can also add CRC functions so it can check the ALL of the ROM chips against a known good list. Adding it in the first socket will end with it checking the last two chips, then moving it will check the first. You could also add an LED (with the supporting hardware) to the board that could be triggered by reading/writing to a specific location, or in general. This would give an instant indicator to if code is running.
There are various techniques to run without a stack. Instead of jump to subroutine, you can do a jump but setting a register to index into a lookup table that will be used to jump back. Changing a subroutine into a macro will duplicate the routine every time you need to use it. It's wasteful but it looks like you have plenty of memory space.
I just want to add, the Z80 has "Shadow Registers" for all of the 8-bit regs. Not a lot of code actually uses these but it's a perfect place to store things like return addresses instead of using the stack. You have to exchange the registers in order to use alternates, the EXX instruction swaps BC DE and HL all in one instruction, you cant access them directly. You can also jump to the addresses stored in IX,IY and HL. I think Zilog was thinking about context switching all the way back in the 1970s, it's crazy to think of having a multitasking OS back then.
THIS IS COMPLETELY WRONG. The ONLY way to increment the PC counter is through the stack. Good luck writing any code that will increment and modify without the stack. Nice try on the EXX flex.
@@Sonex1542 What are even talking about? The PC increments independent of the stack during normal program flow. It's only when you use CALL/RET, PUSH/POP, or when an interrupt fires does the stack do anything. None of the jump instructions use the stack in any way. How do you think the CPU is supposed to initialize and check memory for the stack if it can't function without one?
Yes, the main CPU on the Model I has 16k, and the expansion interface holds 32k for a total of 48, and the roms (level I and II) are 8K each for a total of 64k of addressable space, there are no holes or gaps, although you of course can't write to the rom areas. I remember doing the lower case mod because I worked in a Radio Shack computer center at the time (this was 40 years ago), and I remember the tech telling to do the lower case mod, but I had zero experience, but he grabbed a ram chip and a hunk of wire and threw it at me and I recall it was simply piggybacking the ram chip onto the chip that had the 7 bits. After that, you had to load a driver from cassette or NewDOS 80 had a lower case driver built in. Wow... so long ago, but when you mentioned the 7 bits it all clicked into place, and I realized and now understand what I did. Aside from piggybacking the ram chip, you ran a wire from one pin (that I think was bent up) to somewhere else on the board. I still have that model I, I could take it apart and see where it goes...hmm....
The original RAM memory size on my TRS80 Model 1 if I remember correctly was only 4K. I lived in the UK at that time. I had it upgraded by Tandy to 16K !! and it cost about 100 Pounds sterling ($150) back then (1980) for TANDY to do the 16K upgrade !!
It's rather fun to think that even today there are people still coding stuff together to make sure these vintage computers can be repaired and restored physically and in sfotware, pretty neat stuff... :D
Awesome to see ham callsigns on the screens... makes me think how a Model III would be a perfect machine to do some VHF packet work with an older TNC and radio. The ultimate retro packet data setup!
Testing the full 48K of RAM in one march test is definitely a good idea as it exercises the address decoding (and RAS/CAS gating) towards the DRAM banks. These TRS-80 videos bring back fond memories - I worked in a Tandy store when the model 1 was introduced (and probably sold the first one in the Netherlands, the day after we got it from the warehouse in Belgium). And installing those lowercase mods became something I could almost do with my eyes closed 😄
Yes. Something should prove that the three 16 K banks are distinct, and not just one echoed three times! I have seen this type of issue before, where someone thinks they have more working RAM than they actually have. "Address in Data" is a good test, but on an 8-bit machine you have to be a bit clever to make sure the upper address bits are tested.
Very cool! You should flash the stock rom onto the high side of that eeprom that way you can switch it with the little jumper! Less likely you'll miss a pin swapping back and forth that way :D
The issue really is the ROM adapter PCB can't fit into the real computer fully assembled. It'll hit the RF shield and on the Model 1 I don't think there is room either.
@@adriansdigitalbasement2 Given how you feel about RF shields, you could bust out the Dremel and cut a hole for it. I think that would fit under the heading of "mods that might have been done back in the day" since these are machines that tended to get hacked. Still, putting the normal ROM on the top half would mean having to merge the diagnostic and boot ROMs, and the boot ROM will have to be selected for every machine, and then the whole block written to EEPROM. Granted, the diagnostic part should still work everywhere, but it doesn't seem wise to me to introduce a point of potential operator error.
@@mal2ksc Wherever you put it, you could have a toggle switch routed to the back of the case with "normal/service" printed on it like a traditional vertical-kill switch on a TV 😂
@@adriansdigitalbasement2 A Model I has acres of room inside, the PCB is mounted upside-down in the case and there's the better part of an inch between the ROM socket area and the floor. (And RF shield? What's that?) The trick, however, is that all but the newest Model Is rely on that awful satellite board to hold their three Level II ROMs in, and sandwiching something on that could be painful. So, yeah... "G-board" with the 2-ROM Level II set, no problem, but older ones... And then you have my Model I, which has the awful satellite board terminating in one of the onboard sockets and a Level I BASIC ROM in the other. (And a nasty mess of wire hacks going to a toggle on the back to switch BASICs.) I'm kind of tempted to rip the whole mess out and sub a board with a SST39SF010 and a GAL to switch between Level I and a couple different flavors of Level II, but maybe the agony of dealing with the spaghetti in there builds character.
Very good work. Thanks to all of you. And special thanks to you for your very good made videos and your clear speech, because I'm not English native and it is easy for me to follow. I love it! 👍🏻😊
I didn't really start to see faulty model IIIs until about 1984-ish. At that stage the only digital test equipment I had was a logic probe. Despite the frustrations that led to that I still have most of my hair. A diags ROM back then would have been a godsend. I really should have rolled one myself and made my life easier. Hat's off to the boys and girls (?) for doing this.
The webcam for the talking head in the corner is fine and works well. The new layout with that is much better than before! As always, thank you for sharing your passion and taking the time improve how you share it.
Whoa, didn't think the TRS-80 would have any kind of diag rom. The later disk based ones were good to have, but this leaves me gobsmacked. Super job. I hope this helps a lot of retro persons keep their collections working.
Thanks for another great video! I had the mechanical equivalent of the page error yesterday on a machine: one digital PLC output shorted to another one: forcing one mechanical piston to go out when another goes home, took allot of head scratching to figure out that the multi-conductor cable for it was shorted internally! :D
oh wow, that's a weird problem and a half! If a *cable* is shorted - something went terribly wrong, either if was pulled with force, or pinched etc neighboring cables should be inspected for damage as well.
@@jwhite5008 It's not as strange as it sounds at first, because said multi conductor cable runs in a cable chain so it moves allot, I was still quite confused until I realized exactly what was causing said issue :D
Well Sir. Very well done you and your colleagues. Now you could change the EEROM or EPROM for fast RAM adaptor. Add a two-port interface and then connect to any computer with USB or clunky serial port. As engineer, this is how I/we developed firmware back in the day - 1980's. The adaptor is just the plug-in to memory socket with alternate gnd/signal on ribbon cables (very important, even at 2Mbps). Now you have something akin to an "In Circuit Emulator" where code development becomes very fast, but also avoids much time with burning read-only memory of whatever type. Also, we usually (especially with the Z80) added a simple monitor utility that allowed real-time inspection of memory and CPU registers by means of the very fast RESTART interrupt feature on the Z80 and its derivatives - using the same memory interface by stealing a few bytes of uncommitted RAM for read/write instruction/data. I leave you with the above in the hope it may be helpful.
Since you're using an adapter board for the rom anyway, it would be neat to have a small static ram on the board that maps into some free space to use for a stack for systems with 7 bit or bad video ram. It would probably need at least one other connection for write enable, I think. It's been 30 years since I've directly messed with this stuff.
We actually did a little bit of work on the Kaypro II --- the machine is al ittle easier to fix since every chip is socketed... but a ROM would be nice. The Kaypro doesn't have good documentation so we have to refer to the ROM disassembly to fully understand how bank switching and VRAM works.... but yeah, I'd like to see it there. TRS-80 Model II ROM is next and that's actually working, we just haven't tested it on real hardware yet.
@@adriansdigitalbasement2 Awesome!! I'm sure the Tandy community is jumping for joy! Of you need someone to help teat the Kaypro II diagnostic, I have one and would love to help!
It reports 11110000 when the bus transceiver is absent, which means it still reveals when the fault is something other than a single RAM chip, so I'd say your test is adequate for most purposes.
Yes to be fair, that's what Adrian asked you for. I changed the rules after we started (I moved the goalposts). But I basically learned useful Z80 assembly by reading your original code, so thank you!
@@mal2ksc Actually I meant that the code aborts testing at the first bad BYTE (not bit) and it shows all the bad bits in that particular byte. However it could be changed to accumulate all bit errors in the whole ram segment under test, but that would require another free register and a way to simulate a return from subroutine without the stack (or just unrolling all subroutines). The original code was adapted from custom ROMs I wrote to troubleshoot arcade PCBs like Galaga, Asteroids and Missile Command.
Very cool! I don't have a TRS-80 (well, I have a CoCo 3, but no Z-80 TRS-80's... darn Radio Shack branding confusion), but I'm still very pleased that such a tool has been programmed.
I could be wrong as it was about 1980-ish when I started using the TRS80 model 1. When I modified my TRS80 Model 1 for lower case there were different character generator chips. I'm vague about this because its about 40 years ago. I remember something about true descending characters being an issue too, which can be solved ! A group of us did extensive work on the TRS80. Most of us piggybacked the DRAM to increase it to 32k, 48K etc. I built a 19" expansion rack which had a 64pin back plane, where I could add our home brew boards, like Printer Interface, Disk interface, Real Time Clock, Modem and EPROM Programmer. The first board in the rack was a buffer card using 2x 74LS244 for the address lines and a 74LS245 for the bidirectional Data Bus. The rack internally had separate 5Volt and 12Volt power supplies, I think I had an external 21volt or 24volt supply for the EPROM programmer. I was lucky to work in electronics so parts were very easy to obtain. Being part of that group of TRS80 users was great fun and I learned a lot about computers back then. The group gradually transitioned to the BBC computer and finally PC clones. Unfortunately when I moved to the USA I gave all of my TRS80 equipment to a friend and I have no Idea if any of it still exists today. One other note, some of the early 5 1/4" floppy drives from Tandy/Radio Shack were only 35 track and not 40 track. If you were lucky you could squeeze 38 tracks out of them ! Thanks or the trip down MEMORY lane! (Pun intended)
another great video! Love seeing the TRS80 stuff leading into another sepTANDY! I recently found a CTR-80A cassette drive, do you happen to know if they are particularly hard to find? would be happy to send it over.
What a great explanation. Hopefully I’m not repeating anyone else's comments, but have you also thought of testing other parts of the hardware, or is the assumption that if you can get through these tests, you can get enough running to load more complex tests from normal programs? I did ponder one thing based on bare-metal systems I’ve helped develop before - a ROM diagnostic, eg based on sumcheck or sum such. Of course, there would only be so much badness that could be tolerated on the diag ROM itself and still work enough to test, and testing the secondary ROMs (and character generator ROM, if it’s in the memory map) can perhaps be done once video and RAM is proven.
A while ago I was watching Necroware running those old benchmarks, and Adrian having problems with C64 diagnostic cartridge not displaying all faults, and wondering why someone doesn't update all those things to be better.
A possible technique here, depending on the memory layout of things, could be taking advantage of addresses that never use the top bit. That might mean adding NOPs before a jsr to make sure both the MSB and LSB of the return address don't use the top bit (assuming that's what's missing), but it should allow subroutines to work fine.
Unfortunately it’s not the top bit that’s missing, but bit 6. And it gets filled in as a NOR of bits 5 and 7. In a pinch it might be useful to store some 5-bit RAM variable, but generally useless for anything but VRAM. Also, remember that if using as a stack, each entry is two bytes, so in an address bits 6 and 14 of a 16-bit address are both corrupted. An interesting mental exercise, but just not worth the effort to actually try it.
@@drgiller ah, that is unfortunate. As far as being a "mental exercise" I'd probably write a tool that took it all into consideration (e.g. give the tool a binary, the tool marks any areas that wouldn't work, and suggests fixes/automatically does any fixes)
What about a custom EPROM adapter board for the diagnostic ROM that includes some logic for replacing part of the ROM addresses space with some static ram included in the same boar? This would give you some "reliable" ram for use as stack. Also, one address could be reserved for adding a speaker directly to the "test board", in this way there would not be need for any other hardware working even for the diagnostic sound.
Is there room in the ROM's memory to include diagnostic messages that verbally describe exactly what the problem is, for the beginning user who doesn't really know how to interpret the binary messages? Either way, very nice work! You guys should design a new C64 diagnostic ROM that's more thorough and reliable than the ones we already have.
It should be totally doable. I actually have a CPC so perhaps I'll ask David to make a port. We just need to fully understand how any bank switching works (if it has it) and how the video text display routines work.
Noel of Noel's Retro Lab has written a diagnostic ROM for CPC - not sure how comparable to this one it is but he does have a video up and the code is available etc. He has a video on his channel "Floppy Disk Controller Repair and Diagnostics ROM for the Amstrad CPC"
7 bit vram in the model 1 could be doable for the stack if you are really careful with how you layout things in the rom. Would need to manually align addresses for instructions so bit 6 is never important in return addresses. It would lead to a lot of wasted space in the roms with lots of padding added to get rid of bit 6. Of course you'd ned to also make sure you are careful with all stack usage. Assembler macros could help make this all easier
You could also add the ability to test the 128K RAM that the Model 4 can have, it is very similar to the Model III but supports bank switching of memory past the 64K boundary.
Yeah I was surprised to learn that the ROM was only for Model 1 and 3's, as I thought the Model 4 was compatible. I've got a Model 4P that I wouldn't mind testing with this...
As I said you before, I think that your ROM can be combined very effectively with the ROMulator-Z80 to test these old Z80-based systems and diagnose hardware issues. Give it a try! ;-)
When I got my Mode I for xmas 1979 I asked for the lower-case "kit" too. I still have my entire setup but it hasn't been powered on since 1986 or so. When it was in storage, some mice made the expansion interface home. Still have 4x SD FD drives and a Line Printer V. I don't know what to do with it. I can't bear just disposing of it.
Interesting to see how when you replaced the VRAM chip with a faulty one the "graphics" characters turned into Japanese characters (with a couple of them out of place clearly ponting to a bit error).
I think that points to the fact that the computer was made for the Japanese market _first_ and then modified for the West. Somewhere lies a patch of ROM that didn't need to be recycled and still has all the kana.
@@mal2ksc huh. I wonder where they're hiding. 256 correct ASCII characters means all 8 bits of the generator are being used, I wonder what had to be wrong with that chip to shift it into a higher bank altogether (and what is sticking to double the 64-char lines up)
It's also interesting that the 64-char block drawing pattern line has different margin handling to the other 3 lines. Maybe that "correct" chip is broken too
Speaker or line-input? In the videos, the cassette port is used to drive a "speaker". Is this an actual 8-ohm speaker or is the cassette output used to drive an audio amp?
Instead of using PUSH and POP, use the EXX command to switch to the alternate B, C, D, E, H & L register set. Instead of using CALL and RET, store an 8-bit offset in one of the 8-bit registers which points into a jump table and then use a lookup into the table to find the appropriate address to continue from instead of a RET. It'll take more work to code it this way, but you should be able to make the whole program work without any stack.
correct dont need to use the stack pointer for this, but, he did not require a diagnstic rom at all. had he used a methodical approach at the very start, he would have found the DB problems in first video, IN 30 SECONDS. Should not have abandoned the missing WE at the ram, he should have checked the address and data to them, and the enables. while your there, check the buffered data bus (req a few seconds ) and.......fault. from the cpu side...... SOP check address and data bus and the rom selects and OE, then check the buffered add/data again, would have found it, removing the rom , will not return a 00h , it will be an FFh , reset to 0038h Its going to see how much RAM installed first (probably) check add/ db to ram and not ras/cas....again, problem found he has definatly got a bad track/ connection some where....... AND ITS STILL THERE. the biggest red flag......... the 645's..... 3 of them..... oh aye why. That would have been my first port of call, check previous repair....... litterally seconds. Bet this guy's a teacher. If you cant do - teach did everything wrong and nothing right. moan gripe rant
Great work, guys! I remember doing stuff on my ZS Spectrum in Z80 assembler. So much more flexible than the ZS Basic on the machine. But that was sooooo long ago, I think I forgot everything I ever knew about it. I wish I still had one of those Z80 based computers like the TRS-80 or Commodore 64 to play with. BTW: are all the guys who help you with channel amateur radio operators? I noticed the US and Italian call signs. 73 de M0NMI
Go to the GitHub link in the video description. At the bottom of the README is a link to an _amazing_ emulator for all of the desktop TRS-80 machines. You can get a lot of those memories back. TU ET 73 DE KI3V
Not at this time. We’re going to port it to a few other machines that could use a simple, effective ram testing rom. The Model II is next, and after that probably the Kaypro machines.
For the Model I stack, could you use an upper nibble from one byte, and then a lower one from the next, and so forth, using 2 bytes for one byte of stack?
Not from software. The way the z80 stack works is set by the CPU. Still, there was one thing we could do: rewrite the code to not rely on RAM or stack at all. That’s how the current code runs. No good RAM or VRAM necessary.
Hey Adrian, you might look into this chip... it might make it possable to spool off the stack to the rom that you plug in... :) that way you don't need to change anything for the Model One
If the Z80 stack can be put everywhere, it might be worthwhile for the debug ROM to try to find 64-128 bytes working bytes anywhere in RAM and put the stack there. Even if VRAM is bad with a stuck bit or 2, a human might still be able to guess what some garbled characters and diagnostic text mean.
There are two troubles with this approach. First, achieving what you describe without using a stack (because you have not yet located a trustworthy segment of RAM) is itself not easy! Second, it can be difficult to tell, without intensive testing, exactly which memory locations are the cause, and exactly which are the victims in the memory chips. It's really only if the whole bank is good can you trust any of the RAM in that bank. For instance, the 4116 chips are 16K "deep" or "long", but only one bit wide. So we end up testing 8 chips at a time (which is why the test reports 8 results). If any bits (meaning any of the chips) test bad, you can't really be sure you know all of the addresses within that bank that can be corrupted by access to the bad locations in that bank. It may well be possible with an extensive, complex test, but we don't have the RAM available to undertake that test. So we try to do something useful, which is indicate which chip we know has some bad addresses in it. Fortunately, for recent versions of the test, we don't need RAM or stack at all to get the same results, so we don't need to find a trustworthy section of RAM to be able to print to the screen. VRAM is a bit more tricky though. I like the idea of printing to the screen even if we know there are bad VRAM chips. But in practice, two things argue against it. First, if we detect bad VRAM, filling the screen with the character set is probably the most useful troubleshooting step we can do, as Adrian demonstrated. Second, we have actually tried it, and it was surprisingly difficult to make heads or tails of the display when some of the VRAM bits are bad. So at the moment, we are playing the odds and trying to do what will be the most useful thing, most of the time.
1st Question. Is it possible to use external RAM device with USB connection? Idea: We can connect usb connected RAM so we can have unlimited RAM. 2nd Question. How can I open a software so that I can literally read software's codes?
Is there such a thing as a diagnostic board that plugs into the CPU's socket, containing a socket for the displaced CPU, and with on-board RAM and EPROM (flash?) that could be mapped in to shadow external memory and mapped out to access the external memory? (I could imagine there also being a "window" that maps n pages of the memory map to n pages of the external memory map so that you could check external addresses that would otherwise be shadowed by the diagnostics ROM or workspace RAM.) There wouldn't be any of this problem of not being able to rely on the computer's RAM, buses, or decoding logic. You could have extensive diagnostics without the limitation of having to cram it all into an EPROM that can fit an existing ROM socket. Edit: Oh, and I forgot about it having an on-board serial connection so you could talk it.
Please print exact bytes that are wrong as in first version. This will help in complex issues like faulty buffer or weak drivers. I would also try rely on VRAM as little as possible. It may easily be working but unreliably. A very good memory test otherwise! Thanks! How about a c64 version?
The problem with printing the location in the first version is that they were all in the same chips. It wasn't useful information, and I had to stop the test early to report where the error was found. I made the judgement that it was more useful to try to find as many bad chips as possible than to report where within the chip the error was found. If it's of interest to know where within the chip the error is located, I'm afraid you'll have to use a good hardware RAM tester. As far as using less VRAM, in the current version we don't rely on it at all, managing to make all of the tests and reporting stackless. Unfortunately I know zero 6502 assembly. Adrian tells me Frank's a wizard at it though...
FYI, the expansion interface was never supported with a 4K Model I, and I don't think the EI supported 4K RAMs either, but why would you add 8K to a 16K computer?
The address ranges are off as it seems in yhr video. Two ranges start at 0x4000 and two ejd at 0xFFFF Shouldn’t they represent consecutive, non overlapping blocks?
If you do versions for other systems in future, why not use 8080 (subset of z80 code)? That way you could use the routines on 8080 based computers too 👍🏻
I guess that will depend on how reliant they are on opcodes that aren't in that subset. Also, even if they can be broken down into supported ops, the 8K limit on the ROM might not allow it.
I wish I could. I'd love to try it on my model 102 (which is an 8085, basically an 8080). However, I had to use the IX and IY registers that don't exist on 8080, not to mention most of the Z80-only opcodes. It may be possible, but it's clearly beyond my abilities. Frank might be able to do it.
You should make a “smart” ROM adapter, which has its own SRAM mapped into some unused address space, that way your diagnostic code could work in any system without any modifications.
It wouldn't work in bank-switching machines with a full 64K because they "know" they can't write to "ROM" so don't even have the signal lines to try. It would also require designing a new PCB, when they just cribbed an existing one from somewhere.
@@mal2ksc It turns out the bank-switching machines like the model 2 will write to the underlying RAM when you write to ROM locations. We solved the issue however by _very_ carefully rewriting the tests and drawing routines to require no RAM, relying solely on the Z80 registers for state.
I'd love to see a 6502 port of the march test as well.... especially a stackless one, if possible. All the Commodore 64/PET RAM tests seem to really suck and miss simple things like page errors on the DRAM.
@@adriansdigitalbasement2 stackless on something like a c64 is possible, but reporting back anything meaningfull is going to be rather difficult because video ram is just part of system ram, and the only bit of independent ram you have is color ram, but that is only 4 bit. Oh, and the code is going to be a bit inefficient space wise, as you can't use the zeropage for indirect addressing. On a c128, it should be possible to use vdc for output, but that is a somewhat unique setup for a 6502 machine.
@@c128stuff Can the z80 on the 128 access all the same RAM as the 6502? I don't know c128 architecture (even though I have one that needs troubleshooting). If so, we might be able to adapt this one (though adding it to yours would surely be immensely more useful). If you'd like pointers to the papers I read to implement the March test, let me know and I'll send them your way.
@@drgiller Thanks. The z80 can access most, but not all system ram. For my c128 diagnostics I'm looking at a different approach, making use of the 2 mostly independent blocks of 64k, and the c128 having the for a 6502 rather unique capability of relocating the stack and zeropage, and being able to point the vic2 chip at either ram block. So what I'm thinking for now is to just use vdc for output, do a test on a page in the 2nd ram block and if ok, use that for stack, and run a march test on the 1st ram block, and when done, move the stack to a known good page in the 1st block, and do a match test on the 2nd ram block. That approach is unique to the 128, it won't work on most other 6502 based machines. The march test is both a really clever idea, and a typical case of 'obvious on hindsight', and seems rather trivial to implement, but a reference is always nice 🙂
@@c128stuff The devil is in the details on the march test. I implemented the algorithm after researching it in several places, but it wasn't until considerably later that I understood WHY it's better than more simplistic tests. You have to understand how RAM actually fails. I am sure I am still missing half of the subtleties, but I made sure to carefully follow the algorithm. I may add a checkerboard element to the tests, but I'm not sure that's necessary... cycling through AA and 55 as I'm already doing _might_ catch the same types of errors.
A couple weeks of spare time and a couple of weekends. I had to learn z80 assembly, but I am familiar with assembly programming for several other chips. The first problem is getting something useful running. The second is knowing when to stop!
Just realized, I was thinking 7 bit address lines, not 7 bit data lines. 7 bit data lines makes bytes only register numbers 0-7. If you can somehow limit what gets put on the stack only needs to store 0-7, that would work. I'm sure that wouldn't be easy.
Indeed -- it's ok -- the current version on the Github repo uses no stack at all. This was one of the advances we came up with after I made this video. It uses a simulated stack hardcoded into the ROM. It's really trick!
@@danman32 YT ate my reply but yup, you got it. Although even more sadly it's bit 6, not bit 7 (counting from bit 0), so it's really a mess and not worth the effort. The most useful think a stack can do on a z80 is call/return, and with bit 6 stuck high, it's really useless for that. EDIT: Adiran corrected me: bit 6 is a NOR of bits 5 and 7. I haven't the faintest idea why. But the issue is the same: it can't hold useful values for call/return, so useless as a stack. You might make a case for using it to hold a few bits of RAM variables. I considered using it to keep the offset into a table with less than 63 entries, but ended up not needing to do that.
It's actually worse than that, or at least more complicated. Because of their penny-pinching on bit 6 they were left with a memory that could only hold values 0-63 and 128-191, but since standard ASCII places the (uppercase) letters between 64-95 and they wanted to maintain some compatibility with that they added some read/write mangling hardware so if you write, say, "65" to VRAM it'll produce the expected uppercase letter A... and it'll read back that way, but you'll get the *same* uppercase letter A if you write a "1" to VRAM. (But that "1" will also read back as 65.) This caused all sorts of issues with early lowercase mods for the Model I because there are places in the Level II ROM and some software that got used to the idea that they could write letters to the screen using values 1-26; a straightforward mod that just gives you 8 bit memory with no rewriting causes havoc with the screen display if you can't switch it off. Radio Shack's official lowercase modification *kinda* faked their way around this by replacing the character generator with one that had a duplicate set of glyphs between 0-31 and 64-95, but the whole thing was a mess. Some third party mods retained some of the write mangling logic instead, which would obviously be a disaster if you tried to use video memory for stack or run code from so, yeah. Not a good idea to try on a Model I, generally speaking.
Yes... 6502 stack is at $0100. But for example the C64 dead test cart does not actually need a working stack to do its initial ram test. What it can't do is actually display anything beyond the 'flashes'.
Indeed -- sadly they do a really basic RAM test which is why is is so bad at missing problems. I am not sure this march test can run on a stackless 6502 due there being less registers ... but maybe.
@@adriansdigitalbasement2 I'm not sure you could squeeze anything really useful into a stackless 6502. Maybe you could see if you can dare Frank to try! I _know_ it's beyond my capabilities.
@@adriansdigitalbasement2 less registers, and especially the lack of a register usable as 'pointer' makes for needing a separate loop for each 256 byte page, which is inefficient memory wise, but doable. Reporting back anything meaningfull is more difficult, and keeping track of an error count, or a loop count or such... will make you run out of registers for sure. A for reading/writing/xoring values, X as index register, and Y to keep track of the current write/compare value... should be doable.
@@drgiller I have written a 2 page stackless ram test for 6502, the test itself is doable, just a bit wastefull space wise... the real problem is trying to report anything back, keep track of the number of errors, etc. But 3 registers is just enough to do the actual test.
@@c128stuff Back in 2011 I wrote a simple diagnostic ROM to see if a "dead" Commodore PET had any signs of life, which despite using no RAM managed to communicate a fair amount of information. It had two loops which it alternated between every two seconds: Part 1: fill display memory with four copies of 0-255 so you could visually check if A: anything happened at all, and B: if the resulting output looked correct. (obviously this wouldn't catch arbitrary bit errors, but it'd catch gross RAM errors, problems with the character generators, etc.) Part 2: Do a really brain dead RAM test where "even" and "odd" alternating bit patterns were written to the first 1K of memory, read back, and a result written directly to the corresponding memory location in VRAM. (The result would be a display full of "g"s and "b"s; because "real" 6502 code relies so heavily on the zero page and stack any "b"s in the top half of the screen would probably mean big trouble. The code was a huge mess, of course. Because of the limits of relative jumps, etc, it wasted a huge amount of memory just running through four copies of each test in ROM, etc. (In fairness it was actually the first real 6502 assembly language program I ever wrote.) Much better PETTESTER ROMs have been written since, which do a brain-dead check like my original to see if at least the zero page/stack is usable and switch to a more featureful diagnostic, but I'm kind of proud of my original hack job.
The model 3 has a set of katakana up at the top of the chargen. Seems that the Model 1 replicates the graphics characters twice. So that happens when bit 7 is stuck high on VRAM.
Oh my I had a hilarious idea, you should run the webcam through some filters/post processing to make it look "8-bit" (maybe not THAT bad) for extra hilarious points when people complain about it. Even though it was fine.
![Adrian's Digital Basement ][](http://yt3.ggpht.com/ytc/AIdro_k7CrQRe71qN6c0Ua7A1P_I8KkxjqLa70u0zYeCvdvnKw=s48-c-k-c0x00ffffff-no-rj)
Adrian, that is amazing! When I start watching your channel, it was about C64s and multimeter. Now you are at oscilloscope and creating your own diag ROMs. That’s an amazing journey. And your skill in explaining, your easy to listen voice and your success make your channel my must-watch at weekends.
Due to the small size of the .BIN file for the EPROM being just over 1K, you can get away with a better option for an EPROM that does not require an adapter board. A TI TMS2516 EPROM is pin for pin compatible for the stock ROM ICs, are still readily available as NOS and are reasonably priced. Most EPROM programmers have the capability of programming the 2516 without issue. I tested this for proof of concept just this morning on my 48K Model I, and it works just fine. And yes, your ROM does work on a Model I without issue. Mine does have the lowercase mod with the extra piggyback SRAM to get the 8th bit, so it does work on the VRAM test just fine.
Not only excellent, well presented, educational, and thoroughly enjoyable content, but a real service to the retro computing community too!
I salute you!
I peeked at the code, some really clever and tricky stuff in there. But the thing that really made it possible VRAM test (without stack or ram) and relocating the stack to VRAM is nothing short of genius.
If the VRAM is directly mapped into the memory space, then it's sort of an obvious thing to do. But this apparently is being tailored to work on machines that _don't_ map the VRAM directly into memory space, and _that_ is genius.
One interesting point might have been covered up by Adrian's picture in the corner -- it would have been interesting to see if the last characters on the screen reveal the contents of the stack.
@@mal2ksc The characters do show the stack. It showed in the other video.
Feature Ideas.
Add a second entry point into the ROM so that it can be installed in the ?third? ROM socket (is it compatible?). Then you can also add CRC functions so it can check the ALL of the ROM chips against a known good list. Adding it in the first socket will end with it checking the last two chips, then moving it will check the first.
You could also add an LED (with the supporting hardware) to the board that could be triggered by reading/writing to a specific location, or in general. This would give an instant indicator to if code is running.
There are various techniques to run without a stack. Instead of jump to subroutine, you can do a jump but setting a register to index into a lookup table that will be used to jump back. Changing a subroutine into a macro will duplicate the routine every time you need to use it. It's wasteful but it looks like you have plenty of memory space.
duplicating routines also helps for saving on registers on cpus with very few of those (hello 6502)
I just want to add, the Z80 has "Shadow Registers" for all of the 8-bit regs. Not a lot of code actually uses these but it's a perfect place to store things like return addresses instead of using the stack. You have to exchange the registers in order to use alternates, the EXX instruction swaps BC DE and HL all in one instruction, you cant access them directly. You can also jump to the addresses stored in IX,IY and HL. I think Zilog was thinking about context switching all the way back in the 1970s, it's crazy to think of having a multitasking OS back then.
THIS IS COMPLETELY WRONG. The ONLY way to increment the PC counter is through the stack. Good luck writing any code that will increment and modify without the stack. Nice try on the EXX flex.
@@Sonex1542 What are even talking about? The PC increments independent of the stack during normal program flow. It's only when you use CALL/RET, PUSH/POP, or when an interrupt fires does the stack do anything. None of the jump instructions use the stack in any way. How do you think the CPU is supposed to initialize and check memory for the stack if it can't function without one?
Yes, the main CPU on the Model I has 16k, and the expansion interface holds 32k for a total of 48, and the roms (level I and II) are 8K each for a total of 64k of addressable space, there are no holes or gaps, although you of course can't write to the rom areas. I remember doing the lower case mod because I worked in a Radio Shack computer center at the time (this was 40 years ago), and I remember the tech telling to do the lower case mod, but I had zero experience, but he grabbed a ram chip and a hunk of wire and threw it at me and I recall it was simply piggybacking the ram chip onto the chip that had the 7 bits. After that, you had to load a driver from cassette or NewDOS 80 had a lower case driver built in. Wow... so long ago, but when you mentioned the 7 bits it all clicked into place, and I realized and now understand what I did. Aside from piggybacking the ram chip, you ran a wire from one pin (that I think was bent up) to somewhere else on the board. I still have that model I, I could take it apart and see where it goes...hmm....
The original RAM memory size on my TRS80 Model 1 if I remember correctly was only 4K. I lived in the UK at that time.
I had it upgraded by Tandy to 16K !! and it cost about 100 Pounds sterling ($150) back then (1980) for TANDY to do the 16K upgrade !!
Thank you so much for doing this! It's an iIncredibly useful tool for all the computer archaeologist out there.
It's rather fun to think that even today there are people still coding stuff together to make sure these vintage computers can be repaired and restored physically and in sfotware, pretty neat stuff... :D
Awesome to see ham callsigns on the screens... makes me think how a Model III would be a perfect machine to do some VHF packet work with an older TNC and radio. The ultimate retro packet data setup!
Very Cool !! 73
WOW pulling RAM when on. You are very good at removing chips. These chips can die if the +5 is on without -5 or 12v.
Testing the full 48K of RAM in one march test is definitely a good idea as it exercises the address decoding (and RAS/CAS gating) towards the DRAM banks. These TRS-80 videos bring back fond memories - I worked in a Tandy store when the model 1 was introduced (and probably sold the first one in the Netherlands, the day after we got it from the warehouse in Belgium). And installing those lowercase mods became something I could almost do with my eyes closed 😄
Yes. Something should prove that the three 16 K banks are distinct, and not just one echoed three times! I have seen this type of issue before, where someone thinks they have more working RAM than they actually have. "Address in Data" is a good test, but on an 8-bit machine you have to be a bit clever to make sure the upper address bits are tested.
Very cool! You should flash the stock rom onto the high side of that eeprom that way you can switch it with the little jumper! Less likely you'll miss a pin swapping back and forth that way :D
The issue really is the ROM adapter PCB can't fit into the real computer fully assembled. It'll hit the RF shield and on the Model 1 I don't think there is room either.
@@adriansdigitalbasement2 Given how you feel about RF shields, you could bust out the Dremel and cut a hole for it. I think that would fit under the heading of "mods that might have been done back in the day" since these are machines that tended to get hacked.
Still, putting the normal ROM on the top half would mean having to merge the diagnostic and boot ROMs, and the boot ROM will have to be selected for every machine, and then the whole block written to EEPROM. Granted, the diagnostic part should still work everywhere, but it doesn't seem wise to me to introduce a point of potential operator error.
@@mal2ksc Wherever you put it, you could have a toggle switch routed to the back of the case with "normal/service" printed on it like a traditional vertical-kill switch on a TV 😂
@@adriansdigitalbasement2 A Model I has acres of room inside, the PCB is mounted upside-down in the case and there's the better part of an inch between the ROM socket area and the floor. (And RF shield? What's that?) The trick, however, is that all but the newest Model Is rely on that awful satellite board to hold their three Level II ROMs in, and sandwiching something on that could be painful. So, yeah... "G-board" with the 2-ROM Level II set, no problem, but older ones...
And then you have my Model I, which has the awful satellite board terminating in one of the onboard sockets and a Level I BASIC ROM in the other. (And a nasty mess of wire hacks going to a toggle on the back to switch BASICs.) I'm kind of tempted to rip the whole mess out and sub a board with a SST39SF010 and a GAL to switch between Level I and a couple different flavors of Level II, but maybe the agony of dealing with the spaghetti in there builds character.
Very good work. Thanks to all of you. And special thanks to you for your very good made videos and your clear speech, because I'm not English native and it is easy for me to follow. I love it! 👍🏻😊
I didn't really start to see faulty model IIIs until about 1984-ish. At that stage the only digital test equipment I had was a logic probe. Despite the frustrations that led to that I still have most of my hair. A diags ROM back then would have been a godsend. I really should have rolled one myself and made my life easier. Hat's off to the boys and girls (?) for doing this.
The webcam for the talking head in the corner is fine and works well. The new layout with that is much better than before! As always, thank you for sharing your passion and taking the time improve how you share it.
Very interesting and informative, and it is very generous of all of you who have worked on this project to put it out there in the public domain!
Whoa, didn't think the TRS-80 would have any kind of diag rom. The later disk based ones were good to have, but this leaves me gobsmacked. Super job. I hope this helps a lot of retro persons keep their collections working.
Great as always Adrian. I simply love that fact that both Dave and Franco are HAM Radio Operators!
Thanks for another great video! I had the mechanical equivalent of the page error yesterday on a machine: one digital PLC output shorted to another one: forcing one mechanical piston to go out when another goes home, took allot of head scratching to figure out that the multi-conductor cable for it was shorted internally! :D
oh wow, that's a weird problem and a half!
If a *cable* is shorted - something went terribly wrong, either if was pulled with force, or pinched etc
neighboring cables should be inspected for damage as well.
@@jwhite5008 It's not as strange as it sounds at first, because said multi conductor cable runs in a cable chain so it moves allot, I was still quite confused until I realized exactly what was causing said issue :D
Well Sir. Very well done you and your colleagues.
Now you could change the EEROM or EPROM for fast RAM adaptor. Add a two-port interface and then connect to any computer with USB or clunky serial port. As engineer, this is how I/we developed firmware back in the day - 1980's.
The adaptor is just the plug-in to memory socket with alternate gnd/signal on ribbon cables (very important, even at 2Mbps).
Now you have something akin to an "In Circuit Emulator" where code development becomes very fast, but also avoids much time with burning read-only memory of whatever type.
Also, we usually (especially with the Z80) added a simple monitor utility that allowed real-time inspection of memory and CPU registers by means of the very fast RESTART interrupt feature on the Z80 and its derivatives - using the same memory interface by stealing a few bytes of uncommitted RAM for read/write instruction/data.
I leave you with the above in the hope it may be helpful.
Since you're using an adapter board for the rom anyway, it would be neat to have a small static ram on the board that maps into some free space to use for a stack for systems with 7 bit or bad video ram. It would probably need at least one other connection for write enable, I think. It's been 30 years since I've directly messed with this stuff.
Great diagnostic! Nice how it truly identifies which chips are bad!
Awesome diagnostic adapter!! Fantastic!! Kaypro II diagnostic?? Awesome!!!! Can't wait!
We actually did a little bit of work on the Kaypro II --- the machine is al ittle easier to fix since every chip is socketed... but a ROM would be nice. The Kaypro doesn't have good documentation so we have to refer to the ROM disassembly to fully understand how bank switching and VRAM works.... but yeah, I'd like to see it there.
TRS-80 Model II ROM is next and that's actually working, we just haven't tested it on real hardware yet.
@@adriansdigitalbasement2 Awesome!! I'm sure the Tandy community is jumping for joy! Of you need someone to help teat the Kaypro II diagnostic, I have one and would love to help!
I loved you explanation of marching test test. I could not do better. Nice work.
yes indeed, my routine reports the first wrong bit only :)The repairer should first fix the bad bit then try again :)
It reports 11110000 when the bus transceiver is absent, which means it still reveals when the fault is something other than a single RAM chip, so I'd say your test is adequate for most purposes.
Yes to be fair, that's what Adrian asked you for. I changed the rules after we started (I moved the goalposts). But I basically learned useful Z80 assembly by reading your original code, so thank you!
@@mal2ksc Actually I meant that the code aborts testing at the first bad BYTE (not bit) and it shows all the bad bits in that particular byte. However it could be changed to accumulate all bit errors in the whole ram segment under test, but that would require another free register and a way to simulate a return from subroutine without the stack (or just unrolling all subroutines). The original code was adapted from custom ROMs I wrote to troubleshoot arcade PCBs like Galaga, Asteroids and Missile Command.
I really like the idea of using a known-good video RAM to provide the stack.
It's definitely a pretty ingenious technique
Very cool! I don't have a TRS-80 (well, I have a CoCo 3, but no Z-80 TRS-80's... darn Radio Shack branding confusion), but I'm still very pleased that such a tool has been programmed.
I could be wrong as it was about 1980-ish when I started using the TRS80 model 1.
When I modified my TRS80 Model 1 for lower case there were different character generator chips.
I'm vague about this because its about 40 years ago. I remember something about true descending characters being an issue too, which can be solved !
A group of us did extensive work on the TRS80. Most of us piggybacked the DRAM to increase it to 32k, 48K etc.
I built a 19" expansion rack which had a 64pin back plane, where I could add our home brew boards, like Printer Interface, Disk interface, Real Time Clock, Modem and EPROM Programmer.
The first board in the rack was a buffer card using 2x 74LS244 for the address lines and a 74LS245 for the bidirectional Data Bus.
The rack internally had separate 5Volt and 12Volt power supplies, I think I had an external 21volt or 24volt supply for the EPROM programmer.
I was lucky to work in electronics so parts were very easy to obtain.
Being part of that group of TRS80 users was great fun and I learned a lot about computers back then. The group gradually transitioned to the BBC computer and finally PC clones.
Unfortunately when I moved to the USA I gave all of my TRS80 equipment to a friend and I have no Idea if any of it still exists today.
One other note, some of the early 5 1/4" floppy drives from Tandy/Radio Shack were only 35 track and not 40 track. If you were lucky you could squeeze 38 tracks out of them !
Thanks or the trip down MEMORY lane! (Pun intended)
Great work on the ROM and fixing this beast
another great video! Love seeing the TRS80 stuff leading into another sepTANDY! I recently found a CTR-80A cassette drive, do you happen to know if they are particularly hard to find? would be happy to send it over.
What a great explanation. Hopefully I’m not repeating anyone else's comments, but have you also thought of testing other parts of the hardware, or is the assumption that if you can get through these tests, you can get enough running to load more complex tests from normal programs? I did ponder one thing based on bare-metal systems I’ve helped develop before - a ROM diagnostic, eg based on sumcheck or sum such. Of course, there would only be so much badness that could be tolerated on the diag ROM itself and still work enough to test, and testing the secondary ROMs (and character generator ROM, if it’s in the memory map) can perhaps be done once video and RAM is proven.
Printing a checksum for the ROMs that should be present might be a future enhancement.
A while ago I was watching Necroware running those old benchmarks, and Adrian having problems with C64 diagnostic cartridge not displaying all faults, and wondering why someone doesn't update all those things to be better.
Oh, these ram tests are so much better than basic stuff of the day!
A possible technique here, depending on the memory layout of things, could be taking advantage of addresses that never use the top bit. That might mean adding NOPs before a jsr to make sure both the MSB and LSB of the return address don't use the top bit (assuming that's what's missing), but it should allow subroutines to work fine.
Unfortunately it’s not the top bit that’s missing, but bit 6. And it gets filled in as a NOR of bits 5 and 7. In a pinch it might be useful to store some 5-bit RAM variable, but generally useless for anything but VRAM. Also, remember that if using as a stack, each entry is two bytes, so in an address bits 6 and 14 of a 16-bit address are both corrupted. An interesting mental exercise, but just not worth the effort to actually try it.
@@drgiller ah, that is unfortunate. As far as being a "mental exercise" I'd probably write a tool that took it all into consideration (e.g. give the tool a binary, the tool marks any areas that wouldn't work, and suggests fixes/automatically does any fixes)
The Z80 uses CALL, not JSR.
I feel like there should be a funk / synth wave song titled "Beep out the bad bits".
Amazing work to all of you guys!
This is a great tool, great work all of you! Amazing stuff :)
I love how the ROM credits include the authors amateur radio callsigns. 73! K5JCJ
Adrian - time to write your test! 🙂
What about a custom EPROM adapter board for the diagnostic ROM that includes some logic for replacing part of the ROM addresses space with some static ram included in the same boar? This would give you some "reliable" ram for use as stack.
Also, one address could be reserved for adding a speaker directly to the "test board", in this way there would not be need for any other hardware working even for the diagnostic sound.
There are no peripheral tests? I would arrange for loop--back jumpers to verify the peripheral interface chips.
Is there room in the ROM's memory to include diagnostic messages that verbally describe exactly what the problem is, for the beginning user who doesn't really know how to interpret the binary messages? Either way, very nice work!
You guys should design a new C64 diagnostic ROM that's more thorough and reliable than the ones we already have.
Installed, everything works, thanks!
19:40: It's very intriguing that we're suddenly looking at katakana. Where did those come from?
Love the call signs in the ROM diag. 73 from KI5PBN.
73 de KI3V!
This test ROM is really great! Would love to have such tool for Amstrad CPC...
It should be totally doable. I actually have a CPC so perhaps I'll ask David to make a port. We just need to fully understand how any bank switching works (if it has it) and how the video text display routines work.
I'm sure Noel's Retro Lab would love to have a CPC version too.
Noel of Noel's Retro Lab has written a diagnostic ROM for CPC - not sure how comparable to this one it is but he does have a video up and the code is available etc. He has a video on his channel "Floppy Disk Controller Repair and Diagnostics ROM for the Amstrad CPC"
@@krnlg I'd love to see his code. I'll have to search for it.
“My vram is bugged, everything is in Japanese now”
First rate work! Thanks for all the hard work.
7 bit vram in the model 1 could be doable for the stack if you are really careful with how you layout things in the rom. Would need to manually align addresses for instructions so bit 6 is never important in return addresses. It would lead to a lot of wasted space in the roms with lots of padding added to get rid of bit 6. Of course you'd ned to also make sure you are careful with all stack usage. Assembler macros could help make this all easier
For the random test, if the algorithm can do it, it may make sense to have it display a ? rather than a 0 or 1 if it is not sure of a bit.
You could also add the ability to test the 128K RAM that the Model 4 can have, it is very similar to the Model III but supports bank switching of memory past the 64K boundary.
Yeah I was surprised to learn that the ROM was only for Model 1 and 3's, as I thought the Model 4 was compatible. I've got a Model 4P that I wouldn't mind testing with this...
BTW I’ve confirmed that the Model II banking code doesn’t work properly in the Model 4. But I assume it’s not TOO much different.
As I said you before, I think that your ROM can be combined very effectively with the ROMulator-Z80 to test these old Z80-based systems and diagnose hardware issues.
Give it a try! ;-)
Model 4 version of the diag ROM?
Will this translate to the Model 2 as well?
When I got my Mode I for xmas 1979 I asked for the lower-case "kit" too.
I still have my entire setup but it hasn't been powered on since 1986 or so. When it was in storage, some mice made the expansion interface home. Still have 4x SD FD drives and a Line Printer V.
I don't know what to do with it. I can't bear just disposing of it.
Maybe put it on eBay ? I'd be interested in some of it.
Interesting to see how when you replaced the VRAM chip with a faulty one the "graphics" characters turned into Japanese characters (with a couple of them out of place clearly ponting to a bit error).
I think that points to the fact that the computer was made for the Japanese market _first_ and then modified for the West. Somewhere lies a patch of ROM that didn't need to be recycled and still has all the kana.
@@mal2ksc huh. I wonder where they're hiding. 256 correct ASCII characters means all 8 bits of the generator are being used, I wonder what had to be wrong with that chip to shift it into a higher bank altogether (and what is sticking to double the 64-char lines up)
It's also interesting that the 64-char block drawing pattern line has different margin handling to the other 3 lines. Maybe that "correct" chip is broken too
Speaker or line-input?
In the videos, the cassette port is used to drive a "speaker". Is this an actual 8-ohm speaker or is the cassette output used to drive an audio amp?
It uses the casette port output for sound. You will need an amplified speaker to hear the tones.
How do you read a 2364 mask ROM with a programmer? My GQ-4x4 doesn't have any 23 series mask ROMs
Instead of using PUSH and POP, use the EXX command to switch to the alternate B, C, D, E, H & L register set.
Instead of using CALL and RET, store an 8-bit offset in one of the 8-bit registers which points into a jump table and then use a lookup into the table to find the appropriate address to continue from instead of a RET.
It'll take more work to code it this way, but you should be able to make the whole program work without any stack.
correct dont need to use the stack pointer for this, but, he did not require a diagnstic rom at all.
had he used a methodical approach at the very start, he would have found the DB problems in first video, IN 30 SECONDS. Should not have abandoned the missing WE at the ram, he should have checked the address and data to them, and the enables. while your there, check the buffered data bus (req a few seconds ) and.......fault.
from the cpu side...... SOP check address and data bus and the rom selects and OE, then check the buffered add/data again, would have found it,
removing the rom , will not return a 00h , it will be an FFh , reset to 0038h
Its going to see how much RAM installed first (probably) check add/ db to ram and not ras/cas....again, problem found
he has definatly got a bad track/ connection some where....... AND ITS STILL THERE.
the biggest red flag......... the 645's..... 3 of them..... oh aye why. That would have been my first port of call, check previous repair....... litterally seconds.
Bet this guy's a teacher. If you cant do - teach
did everything wrong and nothing right.
moan gripe rant
Great work, guys! I remember doing stuff on my ZS Spectrum in Z80 assembler. So much more flexible than the ZS Basic on the machine. But that was sooooo long ago, I think I forgot everything I ever knew about it. I wish I still had one of those Z80 based computers like the TRS-80 or Commodore 64 to play with. BTW: are all the guys who help you with channel amateur radio operators? I noticed the US and Italian call signs. 73 de M0NMI
Go to the GitHub link in the video description. At the bottom of the README is a link to an _amazing_ emulator for all of the desktop TRS-80 machines. You can get a lot of those memories back. TU ET 73 DE KI3V
Certainly looks that way !! 73
Are you planning to add tests for other parts of the machine? I/O ports, that kind of thing.
Not at this time. We’re going to port it to a few other machines that could use a simple, effective ram testing rom. The Model II is next, and after that probably the Kaypro machines.
For the Model I stack, could you use an upper nibble from one byte, and then a lower one from the next, and so forth, using 2 bytes for one byte of stack?
Not from software. The way the z80 stack works is set by the CPU. Still, there was one thing we could do: rewrite the code to not rely on RAM or stack at all. That’s how the current code runs. No good RAM or VRAM necessary.
Hey Adrian, you might look into this chip... it might make it possable to spool off the stack to the rom that you plug in... :) that way you don't need to change anything for the Model One
How are you capturing the video from the board?
If the Z80 stack can be put everywhere, it might be worthwhile for the debug ROM to try to find 64-128 bytes working bytes anywhere in RAM and put the stack there. Even if VRAM is bad with a stuck bit or 2, a human might still be able to guess what some garbled characters and diagnostic text mean.
There are two troubles with this approach. First, achieving what you describe without using a stack (because you have not yet located a trustworthy segment of RAM) is itself not easy! Second, it can be difficult to tell, without intensive testing, exactly which memory locations are the cause, and exactly which are the victims in the memory chips. It's really only if the whole bank is good can you trust any of the RAM in that bank.
For instance, the 4116 chips are 16K "deep" or "long", but only one bit wide. So we end up testing 8 chips at a time (which is why the test reports 8 results). If any bits (meaning any of the chips) test bad, you can't really be sure you know all of the addresses within that bank that can be corrupted by access to the bad locations in that bank. It may well be possible with an extensive, complex test, but we don't have the RAM available to undertake that test. So we try to do something useful, which is indicate which chip we know has some bad addresses in it.
Fortunately, for recent versions of the test, we don't need RAM or stack at all to get the same results, so we don't need to find a trustworthy section of RAM to be able to print to the screen. VRAM is a bit more tricky though. I like the idea of printing to the screen even if we know there are bad VRAM chips. But in practice, two things argue against it. First, if we detect bad VRAM, filling the screen with the character set is probably the most useful troubleshooting step we can do, as Adrian demonstrated. Second, we have actually tried it, and it was surprisingly difficult to make heads or tails of the display when some of the VRAM bits are bad. So at the moment, we are playing the odds and trying to do what will be the most useful thing, most of the time.
1st Question. Is it possible to use external RAM device with USB connection? Idea: We can connect usb connected RAM so we can have unlimited RAM. 2nd Question. How can I open a software so that I can literally read software's codes?
I for one would watch a livecoding video of someone coding up that ROM! There's not much retrocoding on Twitch.
Is there such a thing as a diagnostic board that plugs into the CPU's socket, containing a socket for the displaced CPU, and with on-board RAM and EPROM (flash?) that could be mapped in to shadow external memory and mapped out to access the external memory? (I could imagine there also being a "window" that maps n pages of the memory map to n pages of the external memory map so that you could check external addresses that would otherwise be shadowed by the diagnostics ROM or workspace RAM.) There wouldn't be any of this problem of not being able to rely on the computer's RAM, buses, or decoding logic. You could have extensive diagnostics without the limitation of having to cram it all into an EPROM that can fit an existing ROM socket. Edit: Oh, and I forgot about it having an on-board serial connection so you could talk it.
Very good.
Please print exact bytes that are wrong as in first version.
This will help in complex issues like faulty buffer or weak drivers.
I would also try rely on VRAM as little as possible. It may easily be working but unreliably.
A very good memory test otherwise! Thanks! How about a c64 version?
The problem with printing the location in the first version is that they were all in the same chips. It wasn't useful information, and I had to stop the test early to report where the error was found. I made the judgement that it was more useful to try to find as many bad chips as possible than to report where within the chip the error was found. If it's of interest to know where within the chip the error is located, I'm afraid you'll have to use a good hardware RAM tester.
As far as using less VRAM, in the current version we don't rely on it at all, managing to make all of the tests and reporting stackless.
Unfortunately I know zero 6502 assembly. Adrian tells me Frank's a wizard at it though...
FYI, the expansion interface was never supported with a 4K Model I, and I don't think the EI supported 4K RAMs either, but why would you add 8K to a 16K computer?
The address ranges are off as it seems in yhr video. Two ranges start at 0x4000 and two ejd at 0xFFFF
Shouldn’t they represent consecutive, non overlapping blocks?
That is explained in the video. The last test was a single test of the entire RAM all at once. We have since decided that test is not necessary.
Nice.
19:40 Were those Chinese or Japanese characters it was displaying ?
I don’t see the latest ROM on GitHub yet ? Only the 5day old initial version ?
The current version should be what you see on the "main" branch. There is a release called version 1.5. If you can see that, that's the current code.
If you do versions for other systems in future, why not use 8080 (subset of z80 code)? That way you could use the routines on 8080 based computers too 👍🏻
I guess that will depend on how reliant they are on opcodes that aren't in that subset. Also, even if they can be broken down into supported ops, the 8K limit on the ROM might not allow it.
I wish I could. I'd love to try it on my model 102 (which is an 8085, basically an 8080). However, I had to use the IX and IY registers that don't exist on 8080, not to mention most of the Z80-only opcodes. It may be possible, but it's clearly beyond my abilities. Frank might be able to do it.
Wonderful job!
You should make a “smart” ROM adapter, which has its own SRAM mapped into some unused address space, that way your diagnostic code could work in any system without any modifications.
It wouldn't work in bank-switching machines with a full 64K because they "know" they can't write to "ROM" so don't even have the signal lines to try. It would also require designing a new PCB, when they just cribbed an existing one from somewhere.
@@mal2ksc It turns out the bank-switching machines like the model 2 will write to the underlying RAM when you write to ROM locations. We solved the issue however by _very_ carefully rewriting the tests and drawing routines to require no RAM, relying solely on the Z80 registers for state.
Hmm.. and I should add that march test idea to my c128 diagnostics.
I'd love to see a 6502 port of the march test as well.... especially a stackless one, if possible. All the Commodore 64/PET RAM tests seem to really suck and miss simple things like page errors on the DRAM.
@@adriansdigitalbasement2 stackless on something like a c64 is possible, but reporting back anything meaningfull is going to be rather difficult because video ram is just part of system ram, and the only bit of independent ram you have is color ram, but that is only 4 bit.
Oh, and the code is going to be a bit inefficient space wise, as you can't use the zeropage for indirect addressing.
On a c128, it should be possible to use vdc for output, but that is a somewhat unique setup for a 6502 machine.
@@c128stuff Can the z80 on the 128 access all the same RAM as the 6502? I don't know c128 architecture (even though I have one that needs troubleshooting). If so, we might be able to adapt this one (though adding it to yours would surely be immensely more useful). If you'd like pointers to the papers I read to implement the March test, let me know and I'll send them your way.
@@drgiller Thanks. The z80 can access most, but not all system ram.
For my c128 diagnostics I'm looking at a different approach, making use of the 2 mostly independent blocks of 64k, and the c128 having the for a 6502 rather unique capability of relocating the stack and zeropage, and being able to point the vic2 chip at either ram block.
So what I'm thinking for now is to just use vdc for output, do a test on a page in the 2nd ram block and if ok, use that for stack, and run a march test on the 1st ram block, and when done, move the stack to a known good page in the 1st block, and do a match test on the 2nd ram block.
That approach is unique to the 128, it won't work on most other 6502 based machines.
The march test is both a really clever idea, and a typical case of 'obvious on hindsight', and seems rather trivial to implement, but a reference is always nice 🙂
@@c128stuff The devil is in the details on the march test. I implemented the algorithm after researching it in several places, but it wasn't until considerably later that I understood WHY it's better than more simplistic tests. You have to understand how RAM actually fails. I am sure I am still missing half of the subtleties, but I made sure to carefully follow the algorithm. I may add a checkerboard element to the tests, but I'm not sure that's necessary... cycling through AA and 55 as I'm already doing _might_ catch the same types of errors.
So what are you going to name your new BIOS? :)
If those other ROMs are accessible maybe get it to do CRC check of them
Programming a new diagnostic with unfamiliar assembly code ? Why not! :D
Jim Brain has a few different Eprom adapters
You guys are clever! Nice job!
How long did it take to develop this diag ROM?
A couple weeks of spare time and a couple of weekends. I had to learn z80 assembly, but I am familiar with assembly programming for several other chips. The first problem is getting something useful running. The second is knowing when to stop!
With which program you wrote the diagnostic program?
It is written in z80 assembly language. See the linked GitHub page for more details. The code is all there.
@@drgiller oki doki thank you
18:26 So it plays Beethoven's 5th for video ram errors? :D
so remember, when you hear Beethoven, that video hasn't even been invented yet...
I'm sure you can manage to limit your stack usage to only 128 bytes. Then it would work with the 7 bit VRAM on the model 1.
Just realized, I was thinking 7 bit address lines, not 7 bit data lines. 7 bit data lines makes bytes only register numbers 0-7.
If you can somehow limit what gets put on the stack only needs to store 0-7, that would work. I'm sure that wouldn't be easy.
Indeed -- it's ok -- the current version on the Github repo uses no stack at all. This was one of the advances we came up with after I made this video.
It uses a simulated stack hardcoded into the ROM. It's really trick!
@@danman32 YT ate my reply but yup, you got it. Although even more sadly it's bit 6, not bit 7 (counting from bit 0), so it's really a mess and not worth the effort. The most useful think a stack can do on a z80 is call/return, and with bit 6 stuck high, it's really useless for that. EDIT: Adiran corrected me: bit 6 is a NOR of bits 5 and 7. I haven't the faintest idea why. But the issue is the same: it can't hold useful values for call/return, so useless as a stack. You might make a case for using it to hold a few bits of RAM variables. I considered using it to keep the offset into a table with less than 63 entries, but ended up not needing to do that.
@@drgiller so really byte only goes from 0 - 63? I guess that would be true if there's only upper case.
It's actually worse than that, or at least more complicated. Because of their penny-pinching on bit 6 they were left with a memory that could only hold values 0-63 and 128-191, but since standard ASCII places the (uppercase) letters between 64-95 and they wanted to maintain some compatibility with that they added some read/write mangling hardware so if you write, say, "65" to VRAM it'll produce the expected uppercase letter A... and it'll read back that way, but you'll get the *same* uppercase letter A if you write a "1" to VRAM. (But that "1" will also read back as 65.) This caused all sorts of issues with early lowercase mods for the Model I because there are places in the Level II ROM and some software that got used to the idea that they could write letters to the screen using values 1-26; a straightforward mod that just gives you 8 bit memory with no rewriting causes havoc with the screen display if you can't switch it off.
Radio Shack's official lowercase modification *kinda* faked their way around this by replacing the character generator with one that had a duplicate set of glyphs between 0-31 and 64-95, but the whole thing was a mess. Some third party mods retained some of the write mangling logic instead, which would obviously be a disaster if you tried to use video memory for stack or run code from so, yeah. Not a good idea to try on a Model I, generally speaking.
Yes... 6502 stack is at $0100. But for example the C64 dead test cart does not actually need a working stack to do its initial ram test. What it can't do is actually display anything beyond the 'flashes'.
Indeed -- sadly they do a really basic RAM test which is why is is so bad at missing problems. I am not sure this march test can run on a stackless 6502 due there being less registers ... but maybe.
@@adriansdigitalbasement2 I'm not sure you could squeeze anything really useful into a stackless 6502. Maybe you could see if you can dare Frank to try! I _know_ it's beyond my capabilities.
@@adriansdigitalbasement2 less registers, and especially the lack of a register usable as 'pointer' makes for needing a separate loop for each 256 byte page, which is inefficient memory wise, but doable.
Reporting back anything meaningfull is more difficult, and keeping track of an error count, or a loop count or such... will make you run out of registers for sure.
A for reading/writing/xoring values, X as index register, and Y to keep track of the current write/compare value... should be doable.
@@drgiller I have written a 2 page stackless ram test for 6502, the test itself is doable, just a bit wastefull space wise... the real problem is trying to report anything back, keep track of the number of errors, etc. But 3 registers is just enough to do the actual test.
@@c128stuff Back in 2011 I wrote a simple diagnostic ROM to see if a "dead" Commodore PET had any signs of life, which despite using no RAM managed to communicate a fair amount of information. It had two loops which it alternated between every two seconds:
Part 1: fill display memory with four copies of 0-255 so you could visually check if A: anything happened at all, and B: if the resulting output looked correct. (obviously this wouldn't catch arbitrary bit errors, but it'd catch gross RAM errors, problems with the character generators, etc.)
Part 2: Do a really brain dead RAM test where "even" and "odd" alternating bit patterns were written to the first 1K of memory, read back, and a result written directly to the corresponding memory location in VRAM. (The result would be a display full of "g"s and "b"s; because "real" 6502 code relies so heavily on the zero page and stack any "b"s in the top half of the screen would probably mean big trouble.
The code was a huge mess, of course. Because of the limits of relative jumps, etc, it wasted a huge amount of memory just running through four copies of each test in ROM, etc. (In fairness it was actually the first real 6502 assembly language program I ever wrote.)
Much better PETTESTER ROMs have been written since, which do a brain-dead check like my original to see if at least the zero page/stack is usable and switch to a more featureful diagnostic, but I'm kind of proud of my original hack job.
wait wait wait, superfluous? i'm on that Sue-Perflue-us though.
Does this support upper case only systems?
Okay, you just answered the question!
@@melanierhianna I had a similar thought !!
So how is it when the video RAM is bad, it shows Hirigana/Katakana characters rather than the usual high-bit characters?
The model 3 has a set of katakana up at the top of the chargen. Seems that the Model 1 replicates the graphics characters twice. So that happens when bit 7 is stuck high on VRAM.
Best Author
why does it display Japanese Katakana on 19mn 42 ?
I wonder where the Kanji/Kana characters came from? When the working system has Greek characters there. Interesting to say the least.
A model III has two sets of alternate characters, the Greek set and the Kanji set. You switch between them by hitting a bit on an I/O port.
I liked the original tone better. :)
Where did the Japanese characters came from?
The chargen has 32 of them up at the top of the chargen. Check out the github repo and you can see the full character set.
Oh my I had a hilarious idea, you should run the webcam through some filters/post processing to make it look "8-bit" (maybe not THAT bad) for extra hilarious points when people complain about it. Even though it was fine.
* * * W O W - I L O V E I T * * *
hahah too sNice tutorialt
i see ukraine city name in this testy , nice job programmer X)