search

kernelcrash / msx-rom-and-floppy-emulator

Emulate ROMs and Floppy images in MSX
MIT License
39 stars 7 forks source link

label:question cartridge bank switching #1

Closed nightgryphon closed 3 years ago

nightgryphon commented 3 years ago

Hello!

I'm about to build this emulator and reading code to understand how it works. I have a question regarding cartidge bank switching within interrupt.S at write_slot_memory: The data bus is readed to R1 than shifted to lower 0...7 bits at line 676 ldr r1,[r2,C_TO_D_OFFSET+IDR] // read databus again lsrs r1,#8

Than within konami4 and konami5 bank switching at lines 733, 756, 757 bits 8..15 are used. Is that valid? bfi r3,r1,#12,#4

nightgryphon commented 3 years ago

oh. my bad. that's target bits....

kernelcrash commented 3 years ago

No problem. That reg_mapper_pages is not really explained anywhere. Essentially the top 3 bits of it are the cart type as determined when the cartridge file is loaded. And then the bottom 16 bits are four nibbles corresponding to page 1 (bits 15 to 12), page 0 (bits 11 to 8), page 3 (bits 7 to 4) and page 2 (bits 3 to 0). If you look at get_pagemap_default_by_romtype in util.c you can see how these get initialised. For a generic unmapped rom its 1032 corresponding to a contiguous 32K ROM, whereas something like konami 4 is 1000 as page 0 is stuck on 0 and page 1 defaults to 1, and the page 2 and 3 are meant to be random but I just default them to 0. The page 1, page 0, page 3, page 2 sequence relates to the 13 bit shift of the address around 719, 743 etc. basically I want A14,A13 in the bottom 2 bits and I just ignore A15. 0x4000 becomes 10, 0x6000 becomes 11, 0x8000 becomes 00, 0xA000 becomes 01. I think I had the idea that I would just shift by four times those A14/A13 bits to makes things fast ... but rereading the code just now, I didn't end up doing that.

nightgryphon commented 3 years ago

What do you think of idea to migrate this project to STM32H750 ? The goal is to emulate larger cartridges and may be more complex hardware in future. H750 have 1MB RAM and about twice faster than F407. The H750 dev board with extra flash chip and microSD slot costs about $14 at aliexpress including shipping.

This will allow to store the whole cartridge as single block in RAM without need to split on TCRAM/RAM parts so to reduce complexity and responce time.

Also working on my emulation project for soviet "BK 0010" PC i found useful to move interrupt table in to RAM. It will allow to split interrupt handler in two or more separate handlers for different emulation modes and swithch them on mode change. For example to separate FDD and for ROM cartridge handlers. The handler address can be switched on changing FDD/ROM mode on user menu selection. This can simplify handlers and reduce responce time.

kernelcrash commented 3 years ago

I do have a STM32H743 board. I had high hopes for it, but so far I find it a bit annoying to work with. There is no Standard Peripheral library for STM32H7, so I've ended up using the CubeMX thing for some simple projects (ie. I have not tried to port the msx-rom-and-floppy-emulator to it). The early chips only do 400MHz, not 480MHz and there are a couple of pins on port E that are not 5V tolerant (though I'm sure it would probably work 'good enough' without a level converter on those pins). In the experiments I've done , the 400MHz speed didn't really equate to things going much faster (I've kept assuming I've done something wrong, but it could just be that interrupt response is about the same as the old F4 chips and the GPIO bus speeds are still around the same as the older F4 chips too. What I mean is that everytime you do a STR or LDR to GPIO the processor gets slowed down to about F4 speed anyway. I've never tried using the external flash chips on these boards. I've assumed it would be too slow, but I've never tried.

I'd like to play around a bit more with the H7 chips. 400MHz or 480MHz sounds like it should be awesome for this sort of stuff, but I still find the F4 chips easier to work with.

nightgryphon commented 3 years ago

I've got both H743 and H750 boards and now work on FDD/HDD/Memory extension for Soviet PDP-11 based home computer ("BK 0011M"). I use CubeIDE and it seems to work quite well but i use it mostly for statrup initialization code only. I've found the strange issue with port timings. Within the firmware i set some pins on PORTD than after few instructions some pins on PORTA. BUT in some cases i got level change on PORTA BEFORE level change on PORTD. Did you face such issue? How this can be fixed?

kernelcrash commented 3 years ago

Hey. Sorry, I still haven't found much time to play around with the H743 board (having a busy day job). The only thing I've done recently with it is the stm32-flash-programmer thing ... but that's not emulating anything at high speed. The only 'insight' into these chips is that you do have to use a recent gcc with them otherwise they act very strange. I had been using gcc-arm-none-eabi-7-2017-q4-major for a lot of my stm32f4 work ... and that does not work properly with the h7 chips. Now I'm using a 2020 build which seems much more reliable.