Jump to content

flip

Members
  • Content Count

    123
  • Joined

  • Last visited

Community Reputation

116 Excellent

About flip

  • Rank
    Chopper Commander
  1. Yes - it’ll work just fine without a shell... PM me for more details though i’m travelling over the WE so i will probably only reply somewhere next week! FliP
  2. And there's no pre-order list, nor will there be one.
  3. Awesome - that one works like a charm! Thanks. FliP
  4. Has anyone managed to put Loderunner on a flash cart? Is it possible it uses some weird and exotic block size that's currently not supported? Or am I missing something? cheers, FliP
  5. if you have 10 shells left, any colour, i'd be happy to add them to the pi hat order FliP
  6. Hi, The Visicom is actually substantially different from the Studio II (and the color clones) in both hardware and software, despite using the same processor and video chip as the Studio. You might be disappointed with the MPT-02's joysticks: they simply sit on top of the keypad, which in itself is a lot worse than that of the Studio... The multicart is still available, as @stupus pointed out without a shell. PM me for details... FliP
  7. Hi, Long shot, but does anyone have a good quality photo of the inside of an MPT-03 console? Cheers, FliP
  8. The photo has a revision 'B' mainboard, meaning it is very probably a pre-production one. The earliest ones i've seen, the #131 (iFixit teardown) and #155 are revision 'C' boards... The datecode on the CPU (7640) suggests it was put together after week 40 in 1976. Interestingly, two of the ROMs have different serial numbers: 84932 & 84933 are the same as in production machines, but the game roms are 84934 and 84935 - in production machines, they were 85456 and 85457... And the pixie chip has handwriting on it, suggesting it also was a pre-production! Cool find! FliP
  9. Don't think that was ever a condition for the multicart... everyone can have the design, files and all but I asked that they would not be sold commercially. Wouldn't count selling off a single one in an auction as 'commercial'... FliP p.s. congrats on the baby - sad that you have to sell stuff, but i'm sure it'll be worth it!
  10. The multicart hardware itself is still available... Don't think i've posted anything to the contrary? The only thing I don't have is shells/boxes: you'll have to provide your own, but it comes with stickers for the shell and a little manual... FliP
  11. 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
  12. 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
  13. 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
  14. 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
×
×
  • Create New...