• Please review our updated Terms and Rules here

Drop-in NEC V20 CPU Emulator with EMM and MicroSD - MCLV20_Max

Interesting. I wonder if their expansion rom addresses conflict. Can you try changing the xtide address? The BootRom base address can be changed in the header file. @mbucchia

Can you boot from MicroSD if xtide is removed?
 
Last edited:
Because the XTIDE BIOS is at C800h and the SD CARD BOOTROM is at CE00h, it’s probably not an address conflict.

Just to be sure, I removed the XTIDE BIOS and powered on the machine, but the SD CARD BOOTROM still didn’t run. it went straight into internal BASIC. Changing the SD CARD BOOTROM address to D000h gave the same result.
 
As a sanity check can you remove the ISA cards for floppy, HD, and XTIDE? The MCLV20_Max should be able to boot from the MicroSD.

You said it went straight to basic, but did it first try to boot from sd?

Are you sure the MicroSD is bootable?

I suggest preparing the MicroSD with DOS 6.22 (fdisk,format/s) and you may need to use fdisk /mbr as well.
 
Last edited:
Old code
SD Card DOS driver: works.

New code
SD Card DOS driver(New Code): does not work.
SD Card Boot Rom: does not work.

The SD card is formatted as 2 GB FAT in DOS using the FORMAT /S command.


I’m curious what message appears on-screen when the boot rom is detected. If we know that, we can tell whether the boot rom is actually being recognized.

At the moment:
  • If XTIDE is not installed, the machine boots straight into BASIC.
  • If XTIDE is installed, the system starts XTIDE BIOS during boot.

You said it went straight to basic, but did it first try to boot from sd?

So far, I haven’t seen any sign that the system even tries to boot from the SD card. And for some reason, the new SD Card DOS driver that came with the new code doesn’t work either.
 
I just downloaded the MCLV20_Max files from GitHub MCLV20_Max into a new project, set the board to Teensy 4.1, set optimize to fastest, and set CPU speed to 912 Mhz and it worked.

If you comment out line 834 it will use the motherboard's BIOS instead of the Anonymous BIOS inside if the Teensy:

//if ( ((biu_operation&0xF)>=0x4) && (local_address >= 0xFE000) ) return (Test_Image[local_address-0xFE000]); // 8K ROMs

Then I see the below: The BootROM boots from the physical hard disk as C; and assigns the MicroSD as the D: drive. If there was no hard disk it would have booted from the MicroSD.

1752907789308.png

1752907867301.png
 
Last edited:
20250719_155119.jpg

Are you saying the boot rom worked? I went back to square one and started over myself.

I re-downloaded the MCLV20_Max files from GitHub and programmed the Teensy 4.1. My settings match yours.

The CPU emulation appears to run without issues.
The BOOTROM doesn’t seem to start.
The SD card DOS driver also isn’t working.

Should I be using version 1.3 of the SD card DOS driver?
That’s the first thing I want to check.
 
The BOOTROM doesn’t seem to start.
When you use the Anonymous BIOS it clears the screen immediately after the BootRom screen so it is too fast to see it. This is why I suggest using the IBM motherboard ROM which does not clear the screen after the memory test. Then you can see the BootRom loading.

I'm not sure if there is a conflict, but I would not use the XTSD.SYS driver at the same time as the BootROM.

If you want to just use the DOS XTSD.SYS driver without the BootRom then you can comment out the few lines of code which read from the BOOTROM array.
 
I always use the IBM PC XT BIOS.

This time, after commenting out line 834 in the Teensy 4.1 code and running it, something changed: the system no longer boots properly.



View attachment KakaoTalk_20250719_162522058.mp4
For a moment the letters “BR” appear, but I don’t know what they mean.




KakaoTalk_20250719_162512962.jpg
To rule out an address-conflict issue, I’ve removed every card from the motherboard except the CGA card and the memory-expansion card. (The white card visible in the photo is the one that normally plugs into the XTIDE’s SLAVE header, and it isn’t connected to the motherboard at all.)


I’ll investigate further to find out why this issue occurs.
 
You can try uncommenting SuperSoft diagnostics. Maybe try a different Teensy speed or reprogramming the Teensy.
 
One other idea could be to program the board with the acceleration mode set to 3 so that the MCLV20_Max boots always using the internal 640 KB of RAM and none of the motherboard RAM -- in case you have a signal integrity issue.
 
I believe it could work in that application.
Ok, thanks for the info I will try and give feedback (could be tricky with the Janus software handler and the memory bridge between the XT side and the Amiga).

A colleague from A1k.org forum has ordered some pcb´s after updating the scematics (added GND fills and decoupling capacitors, corrected the DRC, etc.).

Is it possible to emulate math copro (8087) too?
 
Ok, thanks for the info I will try and give feedback (could be tricky with the Janus software handler and the memory bridge between the XT side and the Amiga).

I would think it'd be okay as long as it's not "caching" (using onboard memory) for the mailbox area, but of course depending on what exactly you're *doing* with your bridgeboard I could envision issues. (IE, the breakage with DMA, etc. Also the possibility, of course, that there's something in the integration software that's speed sensitive.)
 
Back
Top