+Andrew Davie Posted January 30, 2023 Share Posted January 30, 2023 I thought some of the 6502 people onsite might enjoy this challenge... (my involvement with the CreatiVision console was in contributing ROMs for dumping by Luca - he has been doing an amazing job of archiving and preserving things based on this machine which was popular in a number of countries in the '80s - including Australia. I'd really like if we could help him out and recover the contents of the EPROM, as explained below...). Please share results here, too, if you have a go. "Diagnostic CPU Test, by Vtech (198x)" ====================================== For VTech CreatiVision and compatible computers (Dick Smith Wizzard, Hanimex Rameses, VTech Funvision) This 8 KBytes EPROM was originally found in an authentic cartridge by VTech, for internal use to test functionality of the 6502 CPU in CreatiVision units. It is an insanely rare EPROM (one only ever seen in 20+ years of collecting exclusively CreatiVision items) that I suspect was made in a handful of copies, likely one per each repair centre in countries where CreatiVision sold (I would say no more than 10 EPROMs ever made). The EPROM was used a handful of times and shows a black screen with Assembly data in plain text format, being the test of the CPU commands. Unfortunately, when de-soldering the EPROM from the cartridge PCB, two data lines (bit D1 and D6, or ".X....X.") of each byte were disconnected from the die. The EPROM data remains intact, but these "bits" cannot be "dumped". Therefore, each dump of the named EPROM resulted with bits 1 and 6 being either all 0 or 1, and this alters the content of each byte. The very first dump made (12 January 2009), was limited to the lowest 4 KBytes and it appears to have at least bit 6 with some significant data, although potentially fluctuating/unstable. All following dumps have bits 1 and 6 damaged. The ROM maps the 8 KBytes between $A000 and $BFFF. As this EPROM was one-of-a-kind and it went lost due to mishandling from a MAME team member around 2010, I fear that the full content of this EPROM is lost forever. I have decided to release this collection of "bad" dumps, hoping that someone, one day, will be able to fix it. I have included a little tool called "Biteditor" for Windows, that allows to peek into the EPROM bits and swap 0s and 1s. You may want to use it to attempt to obtain correct bytes/data. If you have any useful information on this, or have a working copy of such EPROM, please do not hesitate to contact me. Thanks Luca Antignano Founder and webmaster of CreatiVemu W: www.madrigaldesign.it/creativemu/ E: lucantignano@gmail.com (5th January, 2023) diagnosticc.zip Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 30, 2023 Share Posted January 30, 2023 (edited) I think there is more broken than just bit 1 and 6. E.g. look at the first byte of each ROM. We have: 0x20 = 0b00100000 0x22 = 0b00100010 0x62 = 0b01100010 0x6E = 0b01101110 While the first three values fit to the description, 0x6E does not. According to this, _2009-10-18_cpu_bad8k_2_2564.bin seems to be even more broken than the other ones. Now lets look at of 0x140. Here we have: 0xFF = 0b11111111 0xFD = 0b11111101 0xBC = 0b10111100 Again, the last one doesn't fit to the description. This comes from _2009-10-18_cpu_bad8k_3_2764adaptor_willem.bin However, overall _2009-10-18_cpu_bad8k_3_2764adaptor_willem.bin looks like a slightly better dump. Bit 6 is at least sometimes correct. _2009-10-16_cpu_bad8k.bin does look even a bit better: And _2009-01-12_cpu_4k.bin seems to have bit 6 always correct: In all other dumps bits 1 and 6 are either set or clear here. So maybe we should concentrate on these three dumps. Edited January 30, 2023 by Thomas Jentzsch 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 30, 2023 Share Posted January 30, 2023 (edited) The code at the beginning of bank 1 seems to do a lot of writing to 0x3000/1. Looks like some kind of serial protocol. EDIT: I found two more (working) ROMs, which seem to have similar code. They also use 0x3000/0x3001 frequently. diagnosticb.zip diagnostica.zip Edited January 30, 2023 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 30, 2023 Share Posted January 30, 2023 (edited) @Andrew Davie How is that different to this CreatiVision Diagnosticcart? EDIT: Nevermind, these are only the two other diagnose ROMs, not the broken CPU one. Edited January 30, 2023 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 30, 2023 Share Posted January 30, 2023 7 hours ago, Andrew Davie said: Unfortunately, when de-soldering the EPROM from the cartridge PCB, two data lines (bit D1 and D6, or ".X....X.") of each byte were disconnected from the die. The EPROM data remains intact, but these "bits" cannot be "dumped". I realise that the physical EPROM is missing, but just out of general interest: were the data lines themselves physically disconnected, or did the legs just break off at / inside the package? If the former, yep, it's decap (or X-ray) time. If the latter, there's a trick I've used on a couple of occasions to get ICs readable enough for whatever purpose they're needed for. Obviously this won't be doable when the chip is MIA, but I am speaking in general terms. Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 30, 2023 Share Posted January 30, 2023 1 hour ago, Thomas Jentzsch said: And _2009-01-12_cpu_4k.bin seems to have bit 6 always correct: True, but that one looks as though bit 6 is always high. I don't know enough about the system to tell if this is intended behaviour or not. Granted, it might be possible to synthesise a 'good' dump from multiple bad ones, but it would need to be marked as suspect at the very least. Munging bad dumps together, calling them good, and sending them out into the wild isn't something I'm particularly keen on. Causes no end of confusion once they spread. *cough*raflsiau*cough* Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted January 30, 2023 Share Posted January 30, 2023 15 minutes ago, x=usr(1536) said: If the former, yep, it's decap (or X-ray) time. If you read further: 7 hours ago, Andrew Davie said: As this EPROM was one-of-a-kind and it went lost due to mishandling from a MAME team member around 2010, I fear that the full content of this EPROM is lost forever. Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 30, 2023 Share Posted January 30, 2023 2 minutes ago, splendidnut said: If you read further: Understood. Hence why I said: 19 minutes ago, x=usr(1536) said: I realise that the physical EPROM is missing Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted January 30, 2023 Share Posted January 30, 2023 Ugh, I need to read better. 1 Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 30, 2023 Share Posted January 30, 2023 8 minutes ago, splendidnut said: Ugh, I need to read better. No worries Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 30, 2023 Share Posted January 30, 2023 (edited) A picture of the cart (at the right) exists: https://gamescollection.forumcommunity.net/?t=60644639https://photos.google.com/share/AF1QipO-1hlvuoXWQuCP9jlfcJH-vdm9UUDXOTkNfk2yWT4aFnsJoLHlpKFgJTl7hahOHg?key=SzVxRGdlR1N6eEdJX0RvZ1c3Tm9xN3BiY0cyMHFB It was in Luca's (aka "Madrigal") collection until at least 2018. Edited January 30, 2023 by Thomas Jentzsch 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 30, 2023 Share Posted January 30, 2023 (edited) 51 minutes ago, x=usr(1536) said: True, but that one looks as though bit 6 is always high. I don't know enough about the system to tell if this is intended behaviour or not. No, that's not OK. 51 minutes ago, x=usr(1536) said: Granted, it might be possible to synthesise a 'good' dump from multiple bad ones, but it would need to be marked as suspect at the very least. 100% agreed. And I doubt we could be even remotely sure that what we create here is even close to the original. Maybe, if we could run the result on a real system, we might get closer. Anyway, as of now I cannot see how we could recreate the original ROM. Opcodes could be guessed with some chance, but the operands are just too random. Maybe we could compare the code to the existing Diag ROMs and find matching pieces of code. But even then, there will be a lot of remaining code and especially non graphics data. IMO. Edited January 30, 2023 by Thomas Jentzsch 1 Quote Link to comment Share on other sites More sharing options...
MADrigal Posted January 31, 2023 Share Posted January 31, 2023 (edited) Hi all - MADrigal here (the owner of the CreatiVision EPROM and person who did the dumps loooong ago) Firstly, thanks Andrew for bringing this to the attention of the community. The situation is quite desperate. I understand that my precious EPROM is lost forever. Have been trying to track it for more than 10 years - with no success. Just providing a few clarifications here The cart is still in my possession, but the EPROM is missing. Yes, the CPU test cart in question came with "Diagnostic A+B" cart - they were part of a single package. No surprise some parts of the code are similar as they were all made for internal use therefore coded by I assume the same persons. The first dump I made (in cronological order) was incorrect in the sense that I dumped the low 4Kb only, so the high 4Kb are missing. On that dump, one only bit is incorrect (bit 1 from memory). So bit 6 is significant - or at least it appears to be. Let's say that missing is: bit 1 in the lowest 4K (first dump) and bits 1 and 6 in the highest 4K (all other dumps). One dump was made after putting the EPROM in the freezer, therefore some data of bits 1 and 6 may be correct or fluctuating - rather than completely incorrect. In relation to writing to $3000 and $3001: this is the CreatiVision VDP address for read/write - see attached "Issue 3" of the Wizzdom fan newsletter containing the entire CreatiVision memory map - needed to understand how the 6502 code is mapped. It is also important to know that the 8K EPROM data end up being "mirrored" in the CPU address space: The 16KB "ROM1" bank ($8000 to $BFFF) is filled up with the EPROM data wtice - which means the same identical content at $8000-$9FFF repeats into $A000-$BFFF. The 6502 can access the same exact content at either $8001 or $A001 getting to the same result. However the ROM code typically assumes the program is at $A000-$BFFF only and the rest is ignored. However there is at least one case of commercial ROM that erroneously points to the "mirrored" area at $8000-$9FFF. When the console boots, the BIOS at $F800 is accessed, the BIOS program does a few inits, then "jumps" in the ROM1 area somewhere around $A000, then the actual EPROM program starts. The BIOS is needed because it tells you where in the ROM1 space the "jump" is (EPROM vector address). The BIOS ROM is available for download from the CreatiVEmu webwsite at: http://www.madrigaldesign.it/creativemu/roms.php All four Wizzdom fanzines contain a lot of info, too, and are tremendously useful: http://www.madrigaldesign.it/creativemu/fanzines.php On a side note - yes the EPROM die is imo intact, but the "traces" between the "legs" (entire) and the actualdie is what I believe went damaged/cut. The idea was for the MAME collaborator to dump via decap, although a bit ambitious because it is not a masked PROM, but an EPROM so I believe the data in the die could look different at microscope. I hope this helps and I look forward to seeing *ANY* form of improvement, theories, data, attempts to fix the EPROM etc. Best program to test the ROM is MAME, followed by CreatiVision Emulator and FunnyMu Unofficial (by myself). Thanks wizzdom3.pdf bioscv.zip Edited January 31, 2023 by MADrigal 3 Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted January 31, 2023 Share Posted January 31, 2023 50 minutes ago, MADrigal said: One dump was made after putting the EPROM in the freezer, therefore some data of bits 1 and 6 may be correct or fluctuating - rather than completely incorrect. Good that the dump was able to be made, but I've always had a difficult time trusting ones made like this without having multiple good redumps from the same source. Then again, if freezing was necessary, something probably wasn't right with the chip to begin with. Not a criticism - I completely understand that circumstances dictate things like this at times 50 minutes ago, MADrigal said: yes the EPROM die is imo intact, but the "traces" between the "legs" (entire) and the actualdie is what I believe went damaged/cut. That's unfortunate. The trick I was alluding to earlier was to take a set of cheap feeler gauges, figure out which one fits in the space where the leg entered the package, and modify it so that it can temporarily replace the leg. This has been successful for me on (literally) a couple of occasions. Not sure how well that would work if the die-to-leg wires / traces are severed. It might be possible to get enough push towards the die on the stub of the old leg that it reestablishes contact, but that also seems like a really easy way to destroy the chip. I have a suspicion - based on the seemingly-fluctuating nature of pins 1 & 6 - that there may be intermittent contact between the die and legs somewhere. This is academic given that the EPROM is missing, but it may be worth keeping in mind in case it ever resurfaces. Quote Link to comment Share on other sites More sharing options...
MADrigal Posted January 31, 2023 Share Posted January 31, 2023 (edited) Thanks for your reply! Unfortunately the "freezing" method was attempted AFTER the damage to the "traces" had occurred. I believe the 4K (partial) dump was done with cartridge adaptor before desoldering the EPROM. All other dumps (8K) were done directly with the EPROM desoldered (and hence, damaged). I attempted to get "a slightly better dump" by freezing it, hoping it would "restore" the traces. I believe that is the "best" of the "bad" dumps overall. I believe if anyone was able to decap the rom, it could be possible to use a laser to re-solder the DIE to the legs - and the problem would be solved. Anyway I lost hope about recovering that EPROM. Re gauges: very clever. I use those gauges in my job (diagnostics engineer) Edited January 31, 2023 by MADrigal 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 31, 2023 Share Posted January 31, 2023 I gave the first bytes of the 4K ROM a try: Dump: SEG CODE ORG $1000 .byte $22 ;.JAM ;0 SRE ram_B2 ;5 ISB $00|$200,x ;7 ;--------------------------------------- .byte $22 ;.JAM ;0 ANC #$36 ;2 ISB $c2ab,x ;7 SAX ram_FA ;3 SAX $00|$200 ;4 ;--------------------------------------- tsx ;2 LXA #$42 ;2 rol ram_FA ;5 .byte $d2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $32b7,x ;7 SLO (PF1|$40,x) ;8 SRE $72b7,x ;7 SLO (PF1|$40,x) ;8 SRE $bab7,x ;7 LXA #$02 ;2 rol $00|$200 ;6 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $32b7,x ;7 SLO (PF1|$40,x) ;8 SRE $72b7,x ;7 SLO (PF1|$40,x) ;8 SRE $22b7,x ;7 SRE ram_B2 ;5 sbc CXP0FB|$200,x ;4 and #$2e ;2 and (CXP0FB,x) ;6 brk ;7 = 159 rol VDELBL ;5 RLA (ram_FF,x) ;8 LXA #$7f ;2 SAX ram_FB ;3 SAX $00|$200 ;4 LXA #$ff ;2 SAX ram_FA ;3 SAX RSYNC|$200 ;4 inc ram_FA ;5 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE L12b7,x ;7 SLO (PF1|$40,x) ;8 SRE $a7b7,x ;7 NOP ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $c6b7,x ;7 NOP ;2 .byte $32 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $d2b7,x ;7 SLO (PF1|$40,x) ;8 SRE $a7b7,x ;7 NOP ;2 SBX #$ff ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $a2b7,x ;7 SLO (ram_D6,x) ;8 NOP ;2 LAX ram_FB ;3 SBX #$7e ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $f6b7,x ;7 NOP ;2 LAX ram_FB ;3 SBX #$7f ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $f6b7,x ;7 NOP ;2 .byte $32 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $eeb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 .byte $32 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $afb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 SBX #$82 ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $ceb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 .byte $12 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $afb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 SBX #$7f ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $feb7,x ;7 SLO ($00,x) ;8 = 275 .byte $32 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $afb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 SBX #$82 ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $deb7,x ;7 SLO ($00,x) ;8 = 40 .byte $12 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $afb7,x ;7 .byte $02 ;.JAM ;0 .byte $02 ;.JAM ;0 SBX #$7f ;2 .byte $f2 ;.JAM ;0 SLO (PF1|$40,x) ;8 SRE $22b7,x ;7 SRE ram_B2 ;5 ISB $00|$200,x ;7 rol ;2 RLA $ff32 ;6 .byte $22 ;.JAM ;0 ISB (ram_A2),y ;8 NOP ;2 ror ;2 ARR #$13 ;2 SAX RSYNC|$200 ;4 ror ;2 ARR #$02 ;2 SAX $00|$200 ;4 ror RSYNC|$200 ;6 SEG CODE ORG $1000 jsr $b045 ;6 sbc.wx $00,x ;4 jsr $362b ;6 sbc $c2ab,x ;4 sta ram_FA ;3 sta.w $00 ;4 clv ;2 lda #$42 ;2 bit ram_FA ;3 bne L101b ;2/3 jmp $b75f ;3 = 39 L101b bmi L1020 ;2/3 jmp $b75f ;3 = 5 L1020 bvs L1025 ;2/3 jmp $b75f ;3 = 5 L1025 tsx ;2 lda #$02 ;2 bit.w $00 ;4 beq L1030 ;2/3 jmp $b75f ;3 = 13 L1030 bmi L1035 ;2/3 jmp $b75f ;3 = 5 L1035 bvs L103a ;2/3 jmp $b75f ;3 = 5 L103a jsr $b247 ;6 sbc.wx $00,x ;4 and #$2e ;2 and ($00,x) ;6 brk ;7 = 25 L1045 bit $07|$20 ;3 and (ram_FF,x) ;6 lda #$7f ;2 sta ram_FB ;3 sta.w $00 ;4 lda #$ff ;2 sta ram_FA ;3 sta.w $01 ;4 inc ram_FA ;5 beq L105e ;2/3 jmp $b75f ;3 = 37 L105e bpl L1063 ;2/3 jmp $b75f ;3 = 5 L1063 lda ram_FA ;3 beq L106a ;2/3 jmp $b75f ;3 = 8 L106a dec ram_FA ;5 bmi L1071 ;2/3 jmp $b75f ;3 = 10 L1071 bne L1076 ;2/3 jmp $b75f ;3 = 5 L1076 lda ram_FA ;3 cmp #$ff ;2 beq L107f ;2/3 jmp $b75f ;3 = 10 L107f ldx #$03 ;2 dec ram_FA,x ;6 lda ram_FB ;3 cmp #$7e ;2 beq L108c ;2/3 jmp $b75f ;3 = 18 L108c inc ram_FA,x ;6 lda ram_FB ;3 cmp #$7f ;2 beq L1097 ;2/3 jmp $b75f ;3 = 16 L1097 inc ram_FA,x ;6 bmi L109e ;2/3 jmp $b75f ;3 = 11 L109e inc.w $00 ;6 bmi L10a6 ;2/3 jmp $b75f ;3 = 11 L10a6 lda.w $00 ;4 cmp #$82 ;2 beq L10b0 ;2/3 jmp $b75f ;3 = 11 L10b0 dec.w $00 ;6 bpl L10b8 ;2/3 jmp $b75f ;3 = 11 L10b8 lda.w $00 ;4 cmp #$7f ;2 beq L10c2 ;2/3 jmp $b75f ;3 = 11 L10c2 inc.wx $01,x ;7 bmi L10ca ;2/3 jmp $b75f ;3 = 12 L10ca lda.w $00 ;4 cmp #$82 ;2 beq L10d4 ;2/3 jmp $b75f ;3 = 11 L10d4 dec.wx $01,x ;7 bpl L10dc ;2/3 jmp $b75f ;3 = 12 L10dc lda.w $00 ;4 cmp #$7f ;2 beq L10e6 ;2/3 jmp $b75f ;3 = 11 L10e6 jsr $b247 ;6 sbc.wx $00,x ;4 rol ;2 and $ff32 ;4 jsr $a2f3 ;6 The opcodes should be about right, but the operands are mostly guessed. The code seems to make at least some sense, but nevertheless I think it is hopeless to try to reconstruct manually like this. 1 Quote Link to comment Share on other sites More sharing options...
MADrigal Posted January 31, 2023 Share Posted January 31, 2023 Question: why ORG $1000? Is it not supposed to start at $B000? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 31, 2023 Share Posted January 31, 2023 4 minutes ago, MADrigal said: Question: why ORG $1000? Is it not supposed to start at $B000? $b000 is correct, the wrong ORG is a result of the tool I used (DiStella). 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.