05177: All studio2 variants: Studio 2 Memory Map does not support cartridges >1k

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05177	Crash/Freeze	Critical (emulation)	Always	Mar 29, 2013, 07:32	Nov 9, 2019, 05:53

Tester	autismuk	View Status	Public	Platform
Assigned To	Robbbert	Resolution	Fixed	OS
Status [?]	Resolved			Driver	rca/studio2.cpp
Version	0.148u2	Fixed in Version	0.216	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	05177: All studio2 variants: Studio 2 Memory Map does not support cartridges >1k
Description	Note: self compiled from AUR - Arch Linux The RCA Studio 2 Memory Map is fluid. ROM cartridges do not fit into a slot on a memory map like they do on most other machines - they connect themselves into block of memory and disconnect whatever hardware is in the system using a bus line. (CDP1831 ROMs self map and do not have external address decoding hardware). It is a convention that game ROMs are placed at $400-$7FF and it is also required that there be ROM at $400 because the BIOS does a jump to $400 in the internal Chip8 languages. These game ROMs disable the BIOS image that is already present at $400-$7FF. Games with images that are greater than 1k e.g. do not fit in this space map themselves to other areas of the memory map - this can be anywhere except the first 1k of Memory. This (incidentally) is why the ST2 format I created is not just simply a binary dump. This bug has appeared because S2 Homebrews >1k have started to appear. Not all S2 ROM images have been dumped and it is possible that there may be larger images on some cartridges.
Steps To Reproduce	Run a >1k cartridge http://www.robsons.org.uk/pacman.zip [broken link] contains pacman.st2 which is a 1.5k image with ROM from $400-$7FF and $A00-$BFF (also attached. not. bug in your upload, won't work) These cartridges work in my development S2 emulator and Emma02 which is a precise emulator for all sorts of 1802 based kit.
Additional Information	From studio2.c static ADDRESS_MAP_START( studio2_map, AS_PROGRAM, 8, studio2_state ) ADDRESS_MAP_UNMAP_HIGH AM_RANGE(0x0000, 0x07ff) AM_ROM AM_RANGE(0x0800, 0x09ff) AM_MIRROR(0xf400) AM_RAM ADDRESS_MAP_END is too simple a definition. I suspect that this defines the memory layout and then when a cartridge image is loaded the contents are copied into whatever structure is linked to via that map. This is somewhat problematic because technically an S2 ROM cartridge can map out the RAM as well. It can also map out individual mirrors - e.g. the RAM image at $C00-$DFF. If you read https://archive.kontek.net/studio2.classicgaming.gamespy.com/techinfo.htm section 17 on RAM decoding RAM is mapped anywhere A9 is '1' and there is no System or Cartridge ROM - I presume this is what AM_MIRROR does. Problem is this only applies if a ROM has not decided to plonk itself there. I suspect that this behaviour is common to things like the Visicom and MPT02 as well. It strikes me that doing this exactly would require serious surgery to the Studio 2/MESS code base for not much gain. A quick fix - keep the C00-DFF mirroring and put ROM in A00-BFF and E00-FFF perhaps. In practice this makes no difference. Every ROM except homebrews found so far is written in Studio2's Chip8 variant. Amongst other things, this always accesses data memory at $800 and puts the Video display at $900 because that's how the BIOS is set up. It is possible that someone has written Chip8 code that writes via the $Cxx mirror (a good reason for keeping it) but the C8 variant cannot access memory outside 0000-0FFF because its only method for doing so is a 12 bit register. so the code above could become (not sure as not a MESSdev) : static ADDRESS_MAP_START( studio2_map, AS_PROGRAM, 8, studio2_state ) ADDRESS_MAP_UNMAP_HIGH AM_RANGE(0x0000, 0x07ff) AM_ROM AM_RANGE(0x0800, 0x09ff) AM_MIRROR(0xf400) AM_RAM AM_RANGE(0x0a00, 0x0bff) AM_ROM (added) AM_RANGE(0x0e00, 0x0fff) AM_ROM (added) ADDRESS_MAP_END
Github Commit

Flags	Noted in Source
Regression Version
Affected Sets / Systems	All studio2 variants

Attached Files

No.09438 autismuk Tester Mar 29, 2013, 07:39	Note from reporter. Apologies for the multiple submissions. I think this is a bug in the Bugtracker. I tried to attach a file pacman.st2 (a file which did not work in the driver) which was thrown back with a type error. I then tried to repost it with a zip file of the same thing which was rejected because of an error which I think means that there was already a file attached. None of the three earlier reports were completed to the point of showing the final screen, they all crashed midway through, but rows seem to have been created in the DB anyway. Paul
No.17136 Robbbert Senior Tester Oct 25, 2019, 14:43	Updated link.
No.17160 Robbbert Senior Tester Nov 9, 2019, 05:53 edited on: Nov 9, 2019, 05:55	Added the ability to map to 0xC00-0xDFF. This fixes all the remaining homebrews: pacman, asteroids, scramble and berzerk. It also allows grandpak (from the software list) to run. The quickloader has also been improved: Bugs fixed, and extra protections against overruns added.