@popolon_, you can find the new build of flash.com here.
That message you usually get if Nextor cannot find the rom segment (14) with the disk driver code. This means it was not written correctly or you flashed my SCC compatible ROM in an ASCII16 mapper. Let me know if that's the case. I can make an ASCII16 rom for you just like I did for the RookieDrive (ascii16+other I/O ports)
You need 16*16KB segments at minimum to run Nextor. So a 128Kb would suffice but there is no room anymore to add extra stuff later to the rom. Also I need to update my flash utility to recognise this chip because it has another identifier.
And if you have a USB Hub it is best to have a powered one. The MSXUSB cartridge and it's CH376s module can only power 500mA.
How are these mappers seen when I just used that minipro command line programmer (SST rom in XGecu pro usb programmer) to burn that nextor.rom? That minipro software just burns that binary, it does not know any mapper.
Now that lintweaker suggestion about that SD card addition could be useful for that keyboard problem.
I tried the new build, but it did not detect the flash rom.
I tried the new build, but it did not detect the flash rom.
The flash utility will print out some numbers when scanning the slots. Can you post these? This will help me to detect the right flash chip.
flash utility output in nms8245 msx:
M: E5, D: CD
M: FF, D: FF
M: FF, D: FF
M: F0, F:FF
actually same output is seen when I tried with that AM29F010 fitted in this module, or no module at all...
I tried to enlarge that rom file by copying it 4 times to bigger file, and burn that bigger file to flash rom. But then the module gave again that driver error at boot. So what kind of binary file would be suitable when burning with separate programmer (TL866II usb in linux pc)?
@S0urceror : testing your low level driver now. so far works fine with latest commit (was unstable day or two ago). But, noticed one strange thing - it blocks the CALL commands from Basic. Say, i can't even do CALL SYSTEM once i entered Basic. It just prints OK immediately for everything (really anything after the CALL) and does nothing
UPD: I found the bully in driver_low.asm
DRV_BASSTAT: ret
Should i add `scf` before `ret` and make a pull request? (IMHO it is not worth a whole pull request, maybe you can just fix it next time you commit bugfixes?)
Should i add `scf` before `ret` and make a pull request?
Already fixed and pushed back to the repository in the USB Storage branch. Thanks for spotting this!