S0urceror/MSX-USB

Fail Rom flash AM29F040

Closed this issue · 25 comments

retrocant commented

Greetings, I am having problems recording the msx-usb flashrom, it gives me the following error:

MSXUSB Flash, (c) 202 S0urceror

M: E5, D: CD
M: CD, D: AB
M: F0, D: 1F
M: FF, D: FF

cannot find slot with flash

I am doing the flash method through the MegaFlashrom

S0urceror commented
retrocant commented

Greetings, I already did the flash / s1 NEXTOR.ROM routine and it doesn't work either, it gives me the same error.

Greetings.

S0urceror commented
retrocant commented

Greetings, I have the CPLD version, I don't know if there were two different versions in that version ... how could I know?

I use FLASH AM29F040

retrocant commented

I just made the two bridges for the SLTSL and RD and it keeps giving me the same error, it doesn't flash me

S0urceror commented
retrocant commented

Greetings, I already made the bridge in the CPLD and it works, I did not know about that bridge, I have it functional.

Now I have a question, there are two versions 0.5 and 0. release.

I have an 8GB FAT32 USB flash drive, version 0.5 works fine and it recognizes the flash drive, but version 0.6 does not recognize the USB.

S0urceror commented
retrocant commented

Greetings, the new boards have arrived, I have also tested revision 0.6 and it works with FAT16 on USB, the only thing I see is that it is not possible to mount DSK disks in this revision.

It occurred to me to be able to work with sofarun but I have installed it and my computer restarts every time I run sofarun.

A greeting.

S0urceror commented
S0urceror commented

Closing this issue, good that we traced the problem down to the reversed OE (output enable) and CE (chip enable). The latest published PCB with the clearly marked v1.0 on the silkscreen does not have this problem.

issalig commented

I cannot make it work. Tested on MSX1 VG-8020 with a pcb v1.0 and also other people reported similar problem with MSX2 f9s

I use a SST39SF040 which should give id BF B7 and I am getting these values

E5 CD
41, 42
41, 42
F0, 0

I checked the codes on http://www.cnc-lab.com/idcodes.txt and they does not seem to fit any IC.

I see that am29 uses addresses 0x555 and 0x2aa but sst39 uses 0x5555 and 0x2aaa , could this be the reason not to detect It?

Any idea?

S0urceror commented
issalig commented

pcb is ok. CE nad OE are connected to SLTSL and RD

I tried to change bytecodes
AM takes 0x555 and 0x2aa
image

and SST 0x5555 and 0x2aaa
image

Results are different now, but still does not work
E5 CD
FE, 5E <---- this was 41,42, the others are the same, and it changes from read to read ???
41, 42
F0, 0

S0urceror commented
issalig commented

Changing to 0x0000 and new adresses does not help. It prints the first 2 slots, then hangs for a little bit and restarts system without detecting msxusb

F0, D3
F0, D3
...

I was having a look at fbelavenuto's update tool https://github.com/fbelavenuto/msxsdmapperv2/blob/2487b3fc9aec44cc669d92146a523a81c66d7061/SW/Updater/src/sdmapper.c#L84 and he is doing similar but writing to IOFW (0x5F that should be a particular register for his card)

Also took a look at the timings if that could be the problem, TIDA and TAA which should be 150+70 = 220ns . if clock is 4Mhz, one cycle would be 250 ns, and I guess that's why there are the dummy readings. And inserted some dummy readings after 0x90 but with same results. I will keep on trying.

image

image

image

image

S0urceror commented
issalig commented

I still do not fully understand the memory map in MSX, I will check this https://www.msx.org/wiki/Slots
From the makefile I see that code is being generated for these addresses --code-loc 0x0180 --data-loc 0 which I assume is the normal MSX start address for programs.

Then, I have seen that this code changes to slot i and page 1 which I guess it is 4000h-07FFFh,

    ld a,(iy)   ;slot
    ld h,#0x40  ;01 00 0000  -> page 1
    jp	0x24 ; ENASLT  jp

I have seen that fbelavenuto https://github.com/fbelavenuto/msx-upd accesses to 9555 instead of 5555, so it seems he is adding the page base adress as an offset. But as you place the pointer of flash_segment to 4000 that would be the same.

I will keep on exploring what's happening.

S0urceror commented
issalig commented

I have been trying different things, but I do not get a clear picture of the RAM/ROM setup.

Slot 0 is for Main ROM 0000-7ffff and RAM 8000-ffff
Let's say I have the msxusb cartridge in slot 1.
In which page resides the msxusb rom? Page 1?
In such a case, access to the first byte of the rom would be flash_segment[0] or flash_segment[4000] ?

I interpret that ENASLT changes the pointer to an specific device, and when we ask for an address instead of RAM we are accesing to ROM. But for example, where are the manufacturer and device variables stored? do they reside in cpu registers?

S0urceror commented

Yes the MSX memory system is fairly elaborate. Luckily on the MSX1 it is still simple.
You have 4 primary slots with each 4 subslot.
System BIOS is always in 0-0 (primary-secondary)
RAM is in your case in 3-0 or 3-2. (VG8020)

In MSXDOS all 64KB RAM is mapped in when the program starts from 0x0100h.
In my current flash program I first scan where the flash sits. It cannot be 0 or 3 but I scan then nevertheless out of simplicity. When it maps in slot 1 or 2 it tries to interrogate it if this is flash memory.

Flash chips normally always return the byte in memory when you read it. And when you normally write it nothing happens. But flash chips do something special if you try to write a series of bytes in a specific order. Then suddenly you don't get the original memory location returned but the information from the chip itself.

This way it knows it's flash and not a normal ROM or RAM.

To complicate matters further our Flash is not a normal 64KB chip but a 512KB chip. I put a SCC compatible mapper in FPGA that detects writes to 0x1000,0x5000,0x9000,0xD000 (flash_segment[0x1000]). When you write a 0 it selects flash page 0 and when you write a 1 it select page 1.

What needs to be changed in the program to make it compatible with your chip?

  • change the __AT flash_segment line back to point to 0x4000
  • copy and paste the select slot 40 routine into a select slot 80 routine and change ld h, 40h to ld h,80h
  • do the same with the select ram slot 40 routine
  • in find_flash under select_slot_40 you add a call to select_slot_80(i)
  • in find_flash under select_ramslot_40 you add a call to select_ramslot_80(i)
  • insert at the beginning of flash_ident two statements to have the right flash pages selected, it now assumes the default
  • this is: flash_segment[0x1000] = 0 and flash_segment[0x5000] = 1
  • update flash_ident to address addresses + 0x4000.
  • So 5555 becomes 9555 and 2aaa becomes 6aaa.
issalig commented

Thanks for the explanation. I am getting a better picture of the situation and I did the changes but the code does not still work and it hangs when scanning slot 2.

Let's try to understand it, flash_segment points to address 0x4000 (page 1, after system rom).
Next, select_slot_40 selects page 1 on slot i, that means we have access to flash chip on msx memory addresses 4000-7ffff
The same is done for slot_80 and msx addresses 8000-BF000

So flash_segment[0] points to 0x4000 that itself points to 0x4000 in slot i (aka our cartridge).

We need to access flash address 0x5555 which resides in the page 1 (4000-7fff) and flash_segment points to 4000. Would not flash_segment[0x1555] be the indirect address to arrive to internal 0x5555 ?

If this is correct, then 0x2aaa could not be reached but I am almost sure I misunderstood sth.

issalig commented

I did a sketch of the idea above

image

S0urceror commented

I am commenting below:

Let's try to understand it, flash_segment points to address 0x4000 (page 1, after system rom). Next, select_slot_40 selects page 1 on slot i, that means we have access to flash chip on msx memory addresses 4000-7ffff The same is done for slot_80 and msx addresses 8000-BF000

That is correct.

So flash_segment[0] points to 0x4000 that itself points to 0x4000 in slot i (aka our cartridge).

It points indeed to 0x4000 to slot i. But what ROM page is mapped there? That depends on a previous write to 0x5000. This triggers the FPGA to select page 0 which is address range 0x00000 to 0x04000. So from now on a write to a CPU address of 0x6aaa is actually targeting flash address 0x02aaa.

We need to access flash address 0x5555 which resides in the page 1 (4000-7fff) and flash_segment points to 4000. Would not flash_segment[0x1555] be the indirect address to arrive to internal 0x5555 ?

If as stated above the CPU address range 0x4000 to 0x7fff points to page 0 being flash range 0x00000 to 0x03fff and we make sure that CPU address range 0x8000 to 0xbfff points to page 1 being flash range 0x04000 to 0x07fff. Then we need to write to CPU address 0x9555 to write to flash address 0x05555.

I'll try to test the above theory out and report back. This would enable you to address 32k of the flash and reach all the addresses the flash-ident and flash-write routines need to function.

issalig commented

Looking at the verilog scc code I see that when a write is detected, the values of a15,a13,a12 establish the following addresses.
| A15 | A14 | A3 | A12 |
| 0 | ? | 0 | 1 | 1XXX, 5XXX
| 0 | ? | 1 | 1 | 3XXX , 7XXX
| 1 | ? | 0 | 1 | 9XXX , DXXX
| 1 | ? | 1 | 1 | BXXX , FXXX

In a similar way a read gives

| A15 | A14 | A3 | A12 |
| 0 | ? | 0 | ? | 0XXX, 1XXX*, 4XXX, 5XXX*
| 0 | ? | 1 | ? | 2XXX , 3XXX*, 6XXX, 7XXX*
| 1 | ? | 0 | ? | 8XXX , 9XXX*, CXXX, DXXX*
| 1 | ? | 1 | ? | AXXX , BXXX*, EXXX, FXXX*

(*) the ones for write.

So for example a write to 0x5000=0 will put mem0 into address_upper and data into mem0
address_upper are the pins A18-A13 and data will be 0 in this case.

case(a15_a13_a12[2:1])
			2'b00: address_upper = mem0;

case(a15_a13_a12)
   3'b001: mem0 = data;

I checked the addresses below with the ones in https://www.msx.org/wiki/MegaROM_Mappers#Konami.27s_MegaROMs_with_SCC
and I am lost at this point. I must find some documentation for dummies because reverse engineering this from code will take me years.