Jump to content

flip

Members
  • Content Count

    137
  • Joined

  • Last visited

Community Reputation

131 Excellent

About flip

  • Rank
    Chopper Commander

Recent Profile Visitors

3,799 profile views
  1. Hi again, I have Azya52's race game running on an unmodified multicart. As indicated before, the multicart does not map $a00-$bff to the cartridge, so I remapped the game to use $100-$7ff and $c00-$fff. Pointers and interrupt are initialised from $000 onwards - the rest of the kernel is left out. I am sure there's a more elegant way of doing it, but it works... Interestingly, this leaves more space for game expansion (though this may need additional shuffling; $400-$4ff is currently not used). To use the game, it needs to have the system's kernel switched off (jumper or switch on the multicart). I've forked Azya52's git to include a new .asm file specifically for the multicart hardware. Due to the exotic timings and resolution, it doesn't run on the PAL clones (MPT-02 & co) or not in any usable way... Attached is a new image that has the racing game in slot 6-0. You'll need a programming device that supports a 39sf040 flash rom (and probably an adapter for PLCC devices). The chip cannot be reprogrammed while on the cart... FliP 39sf040.auto.bin
  2. Hi all, I've managed to get Azya52's racing game running on real hardware. It won't run on the multicart for the moment without a hardware modification unfortunately: an extra address block ($a00-$bff) needs to be mapped to the cartridge. This requires an extra bit of logic on the cartridge. It *might* be possible to shuffle things around, so the game uses $000-$7ff and $c00-$fff, which would make it run on the multicart. Part of the initialisation routine that gets the console up and running would need to be inserted in the code... Interestingly (at least I think it is): my monitor shows some color bleeding around the edges of the objects. Regular games don't do this, so it might be that the timings/higher resolution resemble a PAL signal more than the normal resolutions. Incredible effort by Azya52, stretching the machine to its limits! FliP
  3. Probabl probably why it was never used, in combination with the price of RAM at the time... 192 could be related to the number of lines available in PAL - the total lines =312, which is almost 1/2 of what is available in PAL (625). So each "line" is painted twice on the PAL screen. Interestingly, if you run Studio II games on the PAL consoles using the Studio II kernel, part of the screen is duplicated: the interrupt routine is timed wrong, so it starts redrawing the screen before the beam has reset to line 0. FliP
  4. Pixels and colours used different ram space - there's a third ram chip in the PAL clones. The maximum resolution for the CDP1864 (used in the PAL/color systems) was actually 192x64, but that would have required 1.5k RAM for the pixels, or 6 times what they had in those consoles... FliP
  5. Extremely impressive - the 1861 allows a number of different video resolutions, but the available RAM limits what can be used. I assume there's some clever trickery involved, as 64x128 would normally need 1k of RAM (Studio only has 2 x 256 bytes) it'll be a bit of a challenge to get this running on real hardware, or at least on my multicart. The game uses the $a00-$bff range. In my multicart design, these are not mapped to the cartridge ROM so they are not usable. There may be a way, assuming the game doesn't rely on any kernel routines (by moving the program around and not using the on-board ROMs, in the $000-$3ff range). Still, awesome effort and looking forward to further development... FliP
  6. There was someone working on a 3D model. He had scanned in a cartridge and was converting the scan. I asked a while ago, and I believe he said he abandoned it due to other commitments. He was going to forward the files, but haven't heard back since... The cart works perfectly without a shell - there's no pins to push down and it's clearly marked which side should face the front of the console... FliP
  7. Also, please note that due to the Coronavirus measures, I am unable to post outside Europe for the moment... I advise to wait until things are back to normal. FliP
  8. Hi, Also, please note that due to the Coronavirus measures, I am unable to post outside Europe for the moment... I advise to wait until things are back to normal. It worked for everyone else so far since i started selling these, including someone that transferred money just last week... Not sure what the problem is you are having, but please make sure you use https://www.paypal.me/pmarien It shouldn't ask for an e-mail address? FliP
  9. Hi, Thanks for your message. Two problems unfortunately: I don't have any shells anymore. I had about 15 donated for the initial batch, but they ran out within days... If you have a donor shell, it's easy enough to put the cartridge in... Second issue is that, for the moment, I cannot post to the USA due to the COVID-19 problems. I am in Europe and I have no idea when those services will restart. I'll keep an eye out and let you know, but it could be a few weeks or months... regards, FliP
  10. Is that not what @ekeefe posted about? The cartridge runs in Emma 02 (cart is called computer.st2) if you want to see it "action", but it's fairly cumbersome to use, having to type is code via the keypads, byte by byte and without a way to save it. You don't need extra RAM, but you only have about 200 bytes to play with... FliP
  11. Interesting: a cassette interface like the VIP would require some modifications to the console itself. The VIP uses EF2 to read and Q to write tapes. Q on the SII is used to drive the speaker, EF2 is not used. The cart itself appears to resemble the programming cart that @ekeefe mentioned in this post. Assuming that cassette in/out routines could be added, it would come close to what Mr Wright describes? Taking this further and accepting hardware mods to the console, you could disable the onboard game ROMs using a switch. This would free up the ROMDIS signal on the cartridge port. You could then use that for the MRW signal... Mods to the console would be minimal but you could come close to a VIP. FliP
  12. Hi, Bad RAM is one possibility, but one or more bad ROM chips is also a possible. Do you have any cartridges you can try? If that works, it would mean that the lower ROMs and RAM are OK. If you have the multicart, this can actually replace the entire ROM set and if that works, it would mean the RAM is OK. If no cart works, you'll need to look at replacing the RAM... It'd be happy to help out, if needed. Let me know... FliP
  13. [I thought I had answered this, but it seems to be missing, so maybe I forgot to submit?!?] anyway, your system has a faulty RAM chip - the Studio II has a whopping 512 bytes of RAM. Half of this is working memory - the other half is for the video. They're 4-bit chips, meaning you need two of them for 8 bits: one handles bits 0-3 and the other one 4-7. One of the ones that handles the video is broken, so that you only see half the bits drawn. It's an easy enough fix, if you know how to (de-)solder. You'll need to source a CDP1822 (or equivalent). If you can't find one for a reasonable price, let me know and I should be able to help... I forgot which chip it is on the mainboard, but I can find out if you're planning to try and fix it. FliP p.s. it's unlikely a faulty power supply caused this - these chips are 40 years old and can fail...
  14. I'd be very curious to see how that could be done: it does not seem to possible to add extra RAM via the cartridge port (R/W signal is missing for example). Short of putting nearly the full system (including the CPU) on a cartridge, it doesn't seem very feasible. At best, it would be a very crippled Cosmac VIP, with < 512 bytes RAM to play with? FliP
  15. 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
×
×
  • Create New...