Version 2?

[jdgabbard]

Jordi,

Where you planning on releasing Version 2 of your design?

[msx-solis]

Hi Doug, I work together with more people. we are called MSXmakers! My college has a v2 on it's repository at: https://github.com/capsule5000/O4MEGA_v2 but you can find lots of information at: www.msxmakers.com.

[msx-solis]

If you have any suggestion I will think on a version 3. ;)

[jdgabbard]

Jordi, thank you for the link! I have seen the MSX Makers site. Though, I haven’t joined. Though, as a side note, I too have been working on some MSX components, specifically a docking station for the MX-10: https://retrodepot.net/?p=12593

I do have an idea that I’ve been tossing around. Though we may need to get with Sergey on which signals in are mapped where in the memory space.

One of the suggested improvements to the Omega was to include a TDC-600 circuit into the the computer, or a general purpose IO port so it could be added internally. I was thinking the other day that it might be possible to place the WD37C65 on the memory card in lieu of one of the pages of RAM. And place the bios in one of the pages in the ROM.

The Talent bios would probably still need a patch to accommodate the switching of pages in the Mapper to access it. Along with some circuitry to decode for it on the board. But it seems plausible that it could work.

Have you considered this?

[msx-solis]

"I have to talk to Sergey about which signals are mapped and where in memory space."

I studied the Omega mapper carefully, I hope this article will help you: https://msxmakers.design.blog/proyectos/o4mega/o4mega-circuito/

"The other day I was thinking that it would be possible to put the WD37C65 on the memory card instead of one of the RAM pages. And put the BIOS on one of the ROM pages." The problem with this that you propose is that the TDC600 is accessed by memory addresses in the same slot, but not just any address, I am afraid it is page 2 of the same slot, consecutive to the ROM BIOS page that controls it. I tried putting the TDC BIOS in one slot and the non-BIOS TDC in the second slot and this did not work. Reconfiguring the Omega flashrom is easy, it will be difficult to remove a page from that ROM. To do this, we could perhaps make a hat PCB in the ROM chip socket, but it is not a solution that I liked and I have been working for some time to incorporate one of the Brazilian interfaces, accessed by port. Still WIP.

"The Talent BIOS would probably still need a patch to accommodate page flipping in the Mapper to access it." If you have the ability to modify the operation of that BIOS without accessing the source code you will achieve a milestone. In fact I think it is the same driver included in the RBSC group multicontroller. Of course an integrated controller based on the WD37C65B would be very inexpensive and easy to build, whereas the per port controller relies on the WD2793A-PL02 chip which is more expensive and difficult to locate. However, it is the most used in MSX, it is compatible with SymbOS and would allow the use of FAST-ROM. What if a RAM mapper page has a ROM program burned? Would it be started at POST?

[msx-solis]

If that were the case, we have plenty of available mapper pages to add the floppy interface.

[jdgabbard]

I’ve been looking over the Driver files for another GitHub page recently. After looking at the driver file for the TDC-600, as well as disassembly of the ROM, it may be fairly simple to replace the IO routines with appropriate byte codes to map it to an IO port instead of memory.

Looking at the disassembled ROM, it appears that there are a handful of places where the code accesses the WD37C65. This code could possibly be patched to IN/OUT to an IO port instead of a RD/WR to memory. One thing of note, the driver file I have seen suggests the memory locations for the controller are at 0000-1000h, I noticed your page suggests they are at 8000-9000.

What I haven’t been able to figure out yet are the Data locations of the ROM. They seem to be prefixed and postfixed by some unusual terminators. Assuming I can figure out what those the start and end of the Data locations are I think it’s possible to figure out how to patch it. Alternatively, if I could find the source for Disk Basic 1 I could simply add the appropriate driver routines. But I haven’t found a copy of the source with enough comments to know what it’s doing at this tome.

[jdgabbard]

I also just realized, it would probably be easier to use Nextor, and simply write a driver file for it. However, that project is so large I'm not sure I would know where to begin to understand what is going on.

[msx-solis]

I'm in contact with XaviRompe who who developed Rookie Drive. He can help to modify the driver as he did with it's drive with the Konamiman's support, and he say it's quite easy if we have a prototype acceding to the WD37c65 chip able to access the chip registers. Of course putting the chip after the mapper could be harder enough. Xavi think he can help us to success if no mapper is in the equation, with it we don't know if possible. I think we better would do using a cpu hat and try to access by port to the FDC chip. also a ROM chip hat will be good, replacing a page with the fdc chip itself as do the TDC600 controller itself. As the o4Mega port has not an iorequest pin we have two options: a) add a wire and modify the code to access by port b) put both ROM and FDC chip at the mapper space and modify all the code to support this. All ROMs like DISK BASIC 1 (2 and nextor) has two parts called kernel and driver. the DISK BASIC 1 kernel was developed by Microsoft in all cases, the driver will be only the part modified. Let me know what is your plan, I have not too much experience programming drivers. How wonder if we can take advantage of o4Mega port to get a big ROM warehouse were to have MSX-DOS2 or NEXTOR Kernel without any cartridge slot spent on it. Would you like we beggin to work this first of all?

[jdgabbard]

All we really need is the DOS 1, as that is the low level code for the device to operate. The code for that is disassembled and available here: https://sourceforge.net/p/msxsyssrc/git/ci/master/tree/

I have already downloaded the v1.03 code along with the driver for the TDC-600. I plan on going ahead and working on compiling it. My goal is to convert the mnemonics to PASMO syntax (there is another fork of this on GitHub with the conversion done, though of an older version), and test with my version of the TDC-600 card. Assuming this works, I can then work on modifying the driver file to access the controller through either IO or a page within the mapper.

Since the ROM would have the necessary changes, assuming it has the necessary room to compile in 16k, and is targeted at the Omega, it should be fairly simple from a programming standpoint to access the device. The key will be understanding the memory map of the individual /CS signals of the Mapper, and the pages within the ICs. The idea being that if the code is in ROM it expects to find the controller in a particular page of the Mapper.

Before we commit too much effort to this, I’d like to see if I can get the binary working with my cartridge. Assuming I can get it working, I wouldn’t mind collaborating. But if I cannot get it working there wouldn’t be much point in moving forward with the idea.

[msx-solis]

The assignment of the chip select signal in the o4Mega mapper is sequential, from RAM0_CS (on the motherboard) to RAM7_CS. If, for example, chip # 5 is missing the MSX only recognizes RAM available up to chip # 4. I hope this answer your question.

[jdgabbard]

Jorgi, I have started a repository at: https://github.com/jdgabbard/TDC-600-Source-Code

I'll be working on recreating the source there. Feel free to make any suggestions.