flip

Awesome work on the Test Cart, ED - no wonder it needs a beefed up power supply with all those extra chips... I assume it switches back and forth between the on board ROM and those on the cart to compare them... For the multicart: perhaps you missed the post above, but by patching 4 bytes, you can get the tester to run on the multicart. These are the patches needed, assuming the test cart starts @ 0x0400 0x0417 0x43 --> 0x07 0x041F 0x42 --> 0x06 0x0422 0x40 --> 0x04 0x0601 0x41 --> 0x05 I've attached a patched binary of the test cart that runs on the multicart - it runs all the tests, but gives an error for the roms, depending on whether these are mapped to the cartridge or to the onboard chips... So it doesn't check the full hardware, but the ram and keyboard tests should work... FliP

I've adapted the code - it now runs from 0x4400 but it doesn't make a difference. What does make a difference is to use the little switch on the multicart that determines whether the the first 1k is mapped from the cart or from the console... I've attached the new image, with the code patched as mentioned before... I also tested what happened when using (known) bad chips: a bad rom on the console started the memory test, but with a corrupted screen. The keyboard test crashed as soon as it started. A bad (video) RAM skips the memory test, and goes directly to the keypad test. For the video RAM chips, it gives a failure in 5 & 6, i.e. it marks both as bad meaning it doesn't detect the problem at bit level (each RAM chip handles 4 bits). I am assuming that a failure in the working memory ram would result in codes 7 & 8, though the cart crashes when I put a bad chip in there (not unexpected) I am guessing that a failure of the normal kernel would show 3 & 4 and of the built-in game ROMs would flag as 1 & 2... given that I've had to patch the cart to run on the multicart, I am not entirely sure that it would effectively test the consoles hardware as intended... I think for that purpose, the test I wrote (and that came with the multicart) is a bit more reliable... FliP 39sf040.auto.bin

Interesting thought, but I don't think so: I imagine that the test cart has more chips than a standard cart and that this pushes the power supply just above the normal power supply's limits. But the multicart draws less power overall than any normal cartridge to start with: on my test system (admittedly with a modern dc/dc converter rather than an inefficient 7805 regulator), I draw less than 200mA with the multicart running... It just occurred to me as well that I should be able to map the test cart to 0x4400 rather than to 0x0400 (which is what the patches above do). I'll see whether that makes any difference... It's strange that the system manual doesn't mention what the 'digital failure' codes mean: there seem to be 8 slots, so I assume they refer to the 4 ROM and 4 RAM chips. There's no point in having a CPU or video chip fail indicator as none of this would show... But which chip is which in code is not immediately clear - unless i've missed something in the service manual... It's possible that the test cart somehow switches the internal game roms back on after initializing the test and calculates a checksum. On the multicart, that would be a wrong checksum as it sees the test cart rom rather than the internal game roms... It's a lot to ask for, but it would be really interesting to see the insides of the test cart... FliP

Awesome work getting these carts dumped - a great piece of history preserved! There is some bad news however: the test cart uses some funky memory mapping, which means that it will not readily run on the multicart - or at least not without some modifications... The author of Emma 02 figured out that the cart starts as normal, but quickly switches to an address in the 0x4000 range, where it expects the cartridge to be mirrored. Not entirely sure why it does this, but it seems to be needed to test the system's ROMs and RAM. Interestingly, it also switches the machine to a high resolution mode (which is relative: 64 x 128), showing 4 memory pages: the top half is the top of the cartridge ROMs (0x0600-0x7FFF) and the bottom half is RAM (0x800-0x9FF). It then goes on testing the RAM, by filling it with 0xFF and writing 0x00 to the addresses and a few other patterns... The hardware of the multicart doesn't map anything above 0x0FFF, because it only has a 4-bit latch - that means it has 12 address lines. A good thing is that if the console tries to use an address above that, it just sees the same, i.e. the first 4K are simply mirrored. But since the first 1K (0x0000 - 0x03FF) is mirrored to 0x4000 - 0x43FF (where the cartridge is expected to be), jumping into that region creates problems, i.e. a crash It is however possible to patch the cartridge, so it stops jumping to an area that it not compatible with the multicart. these are the patches needed: 0x0417 0x43 --> 0x07 0x041F 0x42 --> 0x06 0x0422 0x40 --> 0x04 0x0601 0x41 --> 0x05 This stops the program crashing: the memory test runs as does the one for the keypads. On my main test machine, it shows a 'digital failure' as it's called in the service manual by showing 3 & 4 in between the two keypads... I need to dig a bit deeper as to what this means, but it could be linked to not running the program from the correct memory bank... I've attached an image of the test card running on real hardware + multicart. Also attached is a new image for the multicart flash memory, which includes the test card (in slot 4-6). I've moved the demo cart to this bank as well (4-7). Empty slots have a placeholder now, which shows an image on the Studio II (rather than black screen or crashing). If anyone needs this written to their flash chip: either contact me or anyone with an programmer that can handle a 39sf040 flash chip... FliP 39sf040.auto.bin

Wow - for that price, i would definitely want proof that these still work, especially with all the static warnings on the labels... The fact that they have very different shells may indicate they are prototypes or at least very early versions...

I wrote a program to decode the wav files and posted that binary file... There's some degradation/dropouts in the recording, so these have to be corrected manually. I am going to try and see whether I can use the two signals (left and right) to create a more consistent waveform or even combine the four signals (L & R + second recording) to get a more consistent binary dump. The program counts the number of zero crossings to determine whether it's a long pulse (1) or a short one (0). There's only a parity bit at the end of each byte as an error check, so it's difficult to ensure that the signal is correctly decoded. On top of that, the different files appear to be recorded with different hardware/software routines: this particular one seems to be newer than some of the others i've looked at, which conform to what is described in the document scans. In the Fred documentation, one of the last annexes describes the newer method... I'll try to refine the decoder to see whether I get better results... FliP

thanks for the new files - I've not looked in detail, but some appear to be formatted differently - closer to what ekeefe described, with the lead/sync tone immediately before the main part... the wave form is also different, suggesting they've been recorded on a different machine... It makes it a bit harder to decode, as I need to change parameters etc for each individual file. On the up side, they might load on existing hardware/emulators... FliP

I think i've figured out the audio files - ubersaurus pointed to the FRED manual, which contains a description of a tape system for the development system used for the Studio II carts. Confusingly, the initial system used different frequencies and a fixed length (5 ms) to indicate a '1' or a '0'. It was upgraded however to use a more reliable pulse width format: a long pulse indicates a '1' and a shorter one is a '0'. Memo #9 describes this. The data is encoded in 10 bits: a start bit (always '1') followed by the 8 bits in lsb order and a parity bit. This indicates the number of 1s in the main 8 bits: if this is an even number, the parity bit is 1. Otherwise it's 0. It's a very basic error check: it helps but it's far from foolproof... Side one of the digitised tape appears to contain the same file three times, but the third is not complete. The other side appears to be the same program twice. The audio is degraded in several parts, so it needs a manual fix. Not too hard, since it's easy to see whether it's a long pulse or a short one, but time consuming. I've not yet been able to make sense of the binary file that comes out however. It seems that development was done on an advanced version of FRED, or possibly an early Cosmac VIP. The files are 2k, which suggests that it's more than the game itself and includes the kernel for the development system... I've attached the binary of side 1 / part 1 which according to the label is 'swords'. Perhaps someone will recognise it, or can compare it to a known dump of the game... FliP AUD_2464_09_B41_ID01_01_01.rom

Hi all, I've been a bit strapped for time, but I finally got to play with the uncompressed WAV files that ubersaurus provided. I think what ekeefe described is correct as far as structure goes. But it looks like these files are structure differently from those on other RCA systems. The data part consists of long and short pulses, representing individual bits. I've written a small application that parses the data part in the audio file and converts it into bits, and then bytes. Problem here is that we don't know whether a long pulse represents a '1' or a '0'. And we don't know in what order the bits were written: least significant bit first (LSB) or most significant bit first (MSB). Or whether they use any framing (to indicate start and end of a bit - i've not found a pattern in this, but i've not looked very hard yet) or whether there's a header (the first 80 bytes of the first two data blocks on side 1 are identical and diverge after that), or whether there's checksums etc etc. There's about 2.5k data in each block, which suggests there's more in it than just data... If there's any documentation describing the tape format used, this would obviously come in handy. Alternatively, if we could get a wav file of one of the existing games (Studio II Tennis is the most recognizable candidate). That would allow us to compare to existing code dumps and possibly derive a pattern/structure. FliP

Do you know who currently owns this and whether he would be willing to help out by getting it dumped? FliP

In other exciting news: 2 more Visicom carts have been dumped! With the addition of CAS-110 (Maths Drill) and CAS-140 (Gambler I), it means that one (rather illusive) version of Biorythm (CAS-190) remains MIA... Not even sure anyone has ever seen that last one for real - though the same was said about Bingo, so there's hope... I've zipped up all five for your convenience in .st2 format - so they work in the Emma 02 emulator. I'll scan in the manuals and other documents as soon as I have a bit more time - they are in Japanese of course, but they might still be of interest to some... FliP Visicom_carts_st2.zip

Since the power supply of the Studio II is somewhat special (via the RF lead using a splitter box), it may have been necessary to bypass this for testing a console. As I understand, the Tester cartridge had a connector for a special power supply. My guess is that this was a 5v/500mA regulated power supply that provider power directly to the main circuit, without passing via the RF cable. I've made some reproduction cards (single rom boards) that foresee a mini-USB connector. If you plug-in the card, and then the power supply, it fires up the console without the normal power supply. The RF cable can be connected directly to the television without the switchbox. I think this would closely mimic the original Test cartridge, if we ever find the rom image... There's a few tests described in the tape list, so fingers crossed. I've also found some documentation on tape interfaces for the Cosmac VIP - close cousin of the RCA Studio II: http://www.retrotechnology.com/restore/VIP%20Tape%20Format.html FliP

Hi, That's quite exciting news! Converting a wav to data shouldn't be very hard: it is essentially binary data, that needs to be converted to bytes. Nothing a little script can't do... Let us know when you have something! FliP p.s. any sign of a tape containing the code for the test card perhaps?

Well done to Stupus for hanging in there! Here's what the new Visicom dumps look like in Emma 02. No idea what is going on in CAS-141. CAS-160 looks familiar - it's spacewar in color (5 for the rocket game), 0 for the 2-player version... FliP

Some time ago, SlyDC posted a schematic of the Visicom carts. I've been working with stupus to get some of these dumped and we've come across an issue with the pinout that SlyDC drew: address lines 8 and 10 are swapped. This is the correct one: ... Pin 20 = A8 Pin 21 = A9 Pin 22 = A10 So at least 2 of the remaining Visicom carts should become available shortly! FliP

Don't remember either whether it was done before - so here's the insides of a Conic M1200 cartridge. It's very similar to the RCA carts, down to the grounding comb. The trace layout and size of the PCB is a bit different, and has text on it mentioning Conic, so that would suggest that it's a custom redesign... The chip has a copyright date (1979) for the game (concentration in this case) but no date of manufacturing that I can see. FliP

No, the Visicom is an entirely different beast. It's based on the 1802 processor and uses an 1861 video chip (both like the Studio II), but it has it's own system to generate colours. It has two video pages (as opposed to one in the Studio II) and switches between them while an analogue circuit generates the colour. Amongst other things, the code for the games on this system is quite different so that the games for the Visicom are totally incompatible with the other systems. Since we know that the Studio II and III were more or less compatible, the Visicom seems to have been a largely independent development - other than supplying the chips, RCA seems to have had little or no input in its development.

It might be slightly more complicated: the clones use a PAL chip (CDP1864) which would not have worked on the NTSC systems used in the USA. I'm not aware of an NTSC equivalent. It is/was possible to add colour to the 1861 video chip (using an 1862 colour generator) but that combination would not have had multi-tone sound... It's possible RCA had an NTSC chip up their sleeve for the Studio III, but I don't think that's ever surfaced. FliP

Not familiar with the mod itself, but the sound circuit is on the top right of the PCB. It should be possible to get a sound signal between the resistor at the top (see picture, this side is connector to pin 3 of the 555 as mentioned in the mod) and the ground... Tapping it there should generate a slightly different sound (steady instead of the famous dropping wheepy sound). I've had speakers fail because the wire from the solder pad to the coil is very very fine - hardly visible. If you have a multimeter, see if you get a resistance of 6-8 ohm on the speaker. If not, it's definitely broken somewhere. If you do, then it might be the capacitor next to the resistor in the picture... FliP

Long shot, but can you check that the top RF shield (the metal box on the right hand side of the PCB) is on correctly. If this was put on incorrectly at some stage, it grounds the audio circuit, killing the sound... FliP

Hi, Not sure, but I think it could be the CPU clock that has drifted - it doesn't use a crystal but an LC circuit with a tunable coil. If that's too far off the normal 1.76 Mhz, it causes the video signal to be timed wrongly... If you're comfortable opening the console (be careful taking the keyboard connectors off), find the coil in the middle of the board - it stick out and has a hex hole in the top. Carefully insert a hex screwdriver and turn back and forth with the console switched on and playing a game (best is the built-in bowling or racing game). See if that makes a difference... If you have a scope, you should be able see what frequency is on pin 1 of the CPU - it should be around 1.76 Mhz. The sound: most likely culprit is the switch not making contact or the speaker itself broke or was disconnected. The circuit that generates the sound is very simple and is unlikely to fail. I've not come across any Studio II were the caps were the problem. If the power supply is an issue, I don't think it would look like this (more likely to have serious crashes). FliP

Yep - that should work fine. It needs a 9V power supply, with a 3,5mm plug. Tip is positive. FliP

I don't have spare shells anymore - they were donated by Tonymailman but I gave them out on a first-come-first-serve basis. There's an effort to try and reproduce them, but we'll have to see where that goes... I don't have any or make any boxes: Stupus is doing a stellar job with those, so please contact him in case you need a box. Attached is a picture of what included: the bare cartridge, 2 labels (front/back) and a manual. A PDF of the updated manual is also attached The updated order list is on Google Docs If you find your nickname is missing from the list, send me a PM FliP multi_manual_v2.pdf

Hi everyone, I have a new batch of the Mutlicart nearly ready - just waiting for a new set of manuals to arrive, but that should be sorted by next week... The PCB layout has changed a bit, hence the need for a new manual, but there's no changed functionality. I have about 8 or 9 requests, so I'll be contacting those people soon... To be clear: I don't have any more shells, so anyone buying gets the PCB, a set of stickers (in case you have a shell of your own) and a manual. FliP

Hey everyone, Blown away by Marcel's work, triggered by SlyDC: here's Chip-8 Breakout, running on real hardware. It would currently be possible to put this on the multicart, but a small hardware mod is needed on the console (to disable the on-board ROMs that contain the original 'BIOS'). There might be a way around this, so watch this space! FliP