Expected performance?

[zomgugoff]

As there's no description of how this hardware is supposed to perform on the GitHub pages, I wonder if you would be able to describe how compatible Yellow MSX is currently with MSX software (bugs, limitations, performance).

I've been running into hitching/lagging and graphical corruption running cartridges with SROM. I can see this is happening while storage is accessed. It does this even when the ROM is stored on a RAM disk. Not sure why it's accessing storage for a 32k ROM (I assume that's just how the software operates), but I can't imagine that is normal on original hardware.

Floppy disk based games (via Sofarun) seem to be even less compatible. Most of the ones I've tried won't load much. I realize the BASIC being used isn't 100% compatible yet, but games with non-BASIC loaders are failing to load. I also realize Sofarun isn't 100% compatible either, but I've read posts about games I've tried to run working fine with it.

I guess I'm just trying to determine what I should be seeing. Hopefully there's something I'm doing wrong.

[vipoo]

As there's no description of how this hardware is supposed to perform on the GitHub pages, I wonder if you would be able to describe how compatible Yellow MSX is currently with MSX software (bugs, limitations, performance).

My expectation is that the hardware is as compatible as any other MSX system. Although there is no 'certification' or way to validate this. Various schematic designs for MSX system have been published or archived - I am not aware of an hardware elements that are compliant (but of course, there might be unknown issues).

The Turbo CPU is a little different of course - but it running in 3.5Mhz mode should be fully compatible.

There is always potential issues with signal integrity, voltages level - but i have never observed any issues here for the typical kit configurations.

The biggest compatibility challenge is the software stack.

The ROM I distribute, contains the open-source implementation of CBIOS - this is a MSX BIOS (with no BASIC), built from stretch for emulators. I think this kit is the only use of CBIOS in hardware.

The ROM also includes NEXTOR . NEXTOR is very widely used across many MSX machines - so I think this is as good and reliable a MSX-DOS implementation that's possible.

The drivers for NEXTOR that I wrote (USB, Compact Flash), are another story. These are specific to the Yellow MSX series - and may have timing issues that you have observed with SROM. SROM was never design to work with the NEXTOR USB/Compact Flash drivers - those drivers may be causing interrupts to be blocked for periods of time - causing game lagging - not to mention just general performance.

The alternative ROM image, that you have now built, are 'original' MSX software. But its been patched quite a bit. Its reversed engineered from original binary ROM images, then recompiled back into ROM images - there may be bugs or other hidden issues with BASIC/BIOS.

I have not used SROM recently - what I recall was that for some games, I did also see a bit of lagging - but that was with games that needed to be paged. I don't really know how SROM works and loads the games - I suspect its doing some live 'patching' to ensure any bank switching code works. Your experience with SROM is similar to mine - although I don't recall it being an issue for small MSX1 games - eg: pacman and other 16K games.

I may be mistaken in my recall, but I think when running SROM games from the RAM disk - it was not always better.

Also, the version of SROM included in the build, will be rather old I suspect, compared to the latest.

I have not done an exhausted test of games. But all cartridge games that I have run (just a small number) - work perfect.

I also tested a few more games and applications using the MegaFlashROM (SCC+/SD) Cartridge. So long as the NEXTOR versions are align - I remember these working.

I guess I'm just trying to determine what I should be seeing. Hopefully there's something I'm doing wrong.

I don't think so. The only things I can suggest:

1. Try loading the game/image from different hardware (eg maybe copy to the RAM disk)
2. Try small MSX1 16K games under SROM - if they also exhibit lagging - there may be something else going on.

I may struggle to spend time, but if you send me some game examples you have tried - i will try and have a go also to see if I can figure something out. I can not say, at this stage, when I will be able to do look at the games - (Starting a new job IRL on Monday - its gonna eat up some of my personal time for a while)

Hope this helps Dean

[zomgugoff]

Thank you for the in-depth explanation. Based on your explanation, I guess the performance issues I'm seeing would be the result of using the USB/CF storage. I guess the best way to get the expected performance would be to use a MegaFlashROM with the slot extension board. It's on my list of to-do's now.

After making this issue, I started reading through your Hackaday blog and found that early on, you had mentioned an issue with corruption and freezing with Space Manbow. That has been my primary test game and it's happening to me also. Seems that hasn't changed. Although, at the time of that entry, you had not released the Turbo CPU board. I've been using the RC2014 dual clock board at 2.4576MHz as the 3.6864 setting causes corruption (repating characters in DOS, corruption of graphics in games). I wonder if some of the lagging I've been experiencing will be less noticable at 3.5MHz. I'll find out when the kit shows up. Other games I've seen corruption on were just about anything with a constant scrolling background and new graphics coming in from the edges of the screen, like 1942 (or most shooters, for that matter.) Single-screen and non-scrolling games do not appear to suffer the lagging issue.

Rastan has some flickering around the edge of the game window as well as when the player gets near the top of the screen. I suspect that might be related to the clock speed, though. I saw far more flickering around the game window for Psycho World (floppy game) while scrolling.

When I referenced SROM, I was referring to the SofaROM executable included with Sofarun 8.2. It's the most recent version as of this post. I had tried loading from the ramdisk but the lag was only slightly reduced.

As a side note, while trying/failing to get Fire Hawk (Thexder 2) to boot, I stumbled on a hard drive installer for the game with English translation capability and a lot of fixes. I was able to get this to run on Yellow Enchilada, but only after replacing the command2.com with a nerwer version. I was able to pull 2.44 from archive.org's Wayback Machine. There was talk about the 2.4+ versions using far less RAM than 2.31(and adds things like tab-completion). I suspect you didn't include that version with your distribution as it's a modified version of a commercial version. I'm not that fluent in the operation of MSX machines, but I was wondering if there was a way to switch to a command2.com after booting the stock version that would provide all of the benefits. Comspec comes to mind, but I don't think it replaces the resident version.

Anyway, good luck with the new job.

[dinoboards]

I've been using the RC2014 dual clock board at 2.4576MHz as the 3.6864 setting causes corruption (repating characters in DOS, corruption of graphics in games). I wonder if some of the lagging I've been experiencing will be less noticable at 3.5MHz

Hmm that interesting. I would not be surprised you get some issues with games when running at the reduced clock speed. Many games are very tightly coded for the specific speed of MSX. They may be falling behind the VSYNC timings.

I do wonder why you would be getting corruption at the 3.6Mhz speed --- I would not expect that. Is that for both the CBIOS and MSXBASIC rom images?

I will add to me test - to re-test with the original CPU/Dual Clock module - they should work.

In regards to COMMAND2.COM -- probably best is to create a boot USB (or Compact Flash) image - copy NEXTOR.SYS and the COMMAND2.COM you want - if it works with NEXTOR - COMMAND2.COM is basically just another MSXDOS application.

It should be possible to update the build/makefile scripts to copy this specific COMMAND2.COM to the embedded ROM disk -- but its not something i have configured or done.

Cheers Dean

[zomgugoff]

I do wonder why you would be getting corruption at the 3.6Mhz speed --- I would not expect that. Is that for both the CBIOS and MSXBASIC rom images?

That was with both, yes.

I have built a ROM with the updated COMMAND2.COM(Just replacing every instance of it in the build directory). I have yet to see any problems. I also built one with a MSXDOS2.sys that was updated for 2.4+ in place of NEXTOR.SYS in the ROM disk. It worked well also, but there was a compatibility issue with MAPDRV so I switched back.

[zomgugoff]

Just wanted to update after installing the Turbo CPU board. At full speed (20MHz, 1 wait), a lot of the issues I was seeing with hitching in ROM games went away. Space Manbow is still pausing with a full screen of garbage occasionally, but not nearly as often. Disk based games are still being problematic. I can't get the Ys games to boot, for example, but I'm very impressed that the old translated version of Illusion City runs with seemingly no issue. It even ran on my old clock board, just unplayably slow. Things like diskmags and demos are still failing. Seeing some corruption in the text of diskmags, I suspect Kanji data is not present in the ROM. I wonder if there's room in the ROM for that.

Also, the graphical artifacting I mentioned with jitter around play areas is gone.

I have the cartridge expansion board and I'm waiting for a MegaROMSCC+/SD to arrive to perhaps alieviate the disk loading issues.

Perhaps it's time to re-class your creation? It's exceeding MSX2+ with this CPU, but without the R800. So... MSX TurboR-? Or MSX 2++?

[zomgugoff]

Making another update. The MegaROMSCC+/SD has reduced even more of the garbage, but it still has some. At 3.5Mhz, Space Manbow has random background tiles randomly being replaced with other graphics and then returning. At 7.4 or 20Mhz, that tile corruption isn't visable, although there are short lines of colors popping up all over, seemingly in the same place on the screen. I found reference to this on a thread about converting the Omega MSX2 to a MSX2+. The issue was called out as a timing problem.

Other visual oddities are rapid miscolorations on specific screen graphics (the top of the outline of the character protrait in Illusion City, the top area of the screen in Rastan).

General incompatibilities, probably down to the type of cart ROMs I'm trying to run. Still seeing certain disks not want to boot or lock up after the start to boot. Demos are the real test, and some work. Could be C-BIOS stuff too. I'll have to check in an emulator.

[vipoo]

I do vaguely recall running this game when I first got the MFR running. But i haven't tested for quite a while. I certainly would have been running at the standard 3.5Mhz speed. I don't recall having glitches - but perhaps there were some very minor ones. If there were, I would have attributed it to the MFR and/or download image uncertainties.

I am afraid I can't be of much help - the only things I can think of that might be impacting this:

Patched Versions Not sure where you got your image - nor can I recall where I got mine. Perhaps this is a variable - or could be a non issue.

Screen Refresh: Is the game running at 50Hz or 60Hz - I don't imagine your selected ROM image will make a difference - but I would have a 50Hz config on boot. - I doubt it will be an issue - maybe i had downloaded a 'patched' game.

Clock Speed One other difference with this system and other MSX systems, will be minor differences in the clock speeds. A few systems will drive the CPU clock from the an output generated by the VDP, and I believe some came with slightly different clock speeds.

I chose the speed that typical for RC2014 Z80 machines - that seem to be common or near other MSX machines. Space Manbow may be sensitive to the different clock - or may assume the CPU clock is driven from the VDP. Not sure.

It may be possible to patch a line from the CLOCK out of the VDP and send it over to the CPU's headers for the slow clock (remove the jumper and get the clock from the VDP). This is not something I have done or looked at - not sure if its even possible.

[zomgugoff]

I've tried several ROMs for Space Manbow. It's a Japan-only game so it's 60Hz. The latest ROM I've been using is from the 2012 TOSEC collection, so I think it's a clean un-altered dump. I've also encounted these artifacts with the installed version of Fire Hawk. No ROM, disk image, or MFR installed.

Connecting the VDP out clock to the CPU was an easy test. Unfortunately, the problem persists.

Here are short videos of the glitching. You can see the tiles flickering to other graphics or disappearing entirely.

https://youtu.be/dZbFfQQkKpo https://youtu.be/5J9lKRmoA_w

[vipoo]

Hmm. I see what you mean. Its not something I recall ever observing.

The only time I get visual discrepancy typically is when I run certain apps with the CPU running in Turbo mode - where the app is sending commands/writes to the VDP faster than it can processes.

Not sure when I will be able to try attempt to conduct a full test myself to attempt to reproduce issue - but i will try as soon as I can.

I can only speculate as to what's going on here. I am wondering if there might be a VRAM issue -- (I could be off the mark, and its always possible that regression has crept into my most recent designs). I do test the the ram chips - but not in games - i just run a simple RAM tester app. I dont recommend trying to get other RAM chips - as I could be way off the mark - but if you have spares - or maybe even just swap them around a bit.

[zomgugoff]

While the RAM issue has been a common suggestion for any corruption I've read about, I don't have any distortions in text modes nor in most demos I can get to run. Rearranging the RAM doesn't seem to change the behavior either. I would expect to see some change there if any of the RAM is faulty.

[zomgugoff]

I decided to try a little experiment. You mentioned previously just how tight timing needs to be on a MSX. So, I replaced the main osscilator with a 7.15909MHz crystal - 2x the 3.579545MHz clock on a real MSX. Artifacts are all gone at the original speed. Some minor short lines of pixels occur at 7.15909 with either 1 or 3 waits.

It's probably worth mentioning in the documentation.

[vipoo]

That's excellent news and quite interesting. Well done. And thank you very much for the discovery and testing.

This discussion (https://www.msx.org/forum/msx-talk/hardware/msx-z80-clock-frequency) does show that some of the machine had slightly different clocks - perhaps more of a region difference (50Hz/60Hz).

I am still a little confused though, given your experiment with driving the CPU from the VDP's clock-out did not resolve the issue. The VDP has a clock input of 21.47727, and with VDP clock out divided by 6 - should give 3.57955. If this were to work, then I could look at creating another revision of the VDP module and Turbo CPU to allow for the optional use of the VDP's clock for the main bus clock.

I could be wrong, but I thought most MSX machines drove their CPU from the Video's clock. Maybe MSX2+ machine differ here. I have seen some msx.org discussions and other sources stating slightly difference frequencies for different MSX platforms.

But nonetheless, it appears from your experiments that the RC2014 clock of 3.68640Mhz is perhaps just a little bit too fast for some games. That's the clock rate for the official RC2014 Dual CPU clock module, and was chosen to enable the typical baud-rate for SIO/2 serial module.

I will, asap, update the readme's to detail your learning here.

Thanks again

[zomgugoff]

I now realize I had the VDP clock connected incorrectly. It was doing nothing, which explains why I saw no change. If it get a chance, I'll check the circuit diagram to tap the right points and connect them to the clock input.

Having the original clock available on the switch would be nice. There is something unappealing about jumpering between the boards (mostly because all of my jumpers are garbage and get loose after 1 use), but it would make sense to do it that way.

[zomgugoff]

After disconnecting the CPU side of R5 on the turbo board, I connected it to pin 8 of the V9958 and ran the system at base speed. It seemed to run just as well as the divided crystal I installed. Though, the 47K resistor probably should have been left in-circuit.

It's a viable method for providing the "original" clock to the CPU. I wonder if it will be that simple to implement while leaving the undivided CLK1 signal available.

[vipoo]

Hi Mate,

Thats excellent. Let me express my thanks for all the testing and 'fixing' you have done. Really appreciated.

Perhaps some optional jumpers on the Video Module and TurboCPU Module. Stop the TurboCPU from generating a bus clock and make it 'receive' the clock via the backplane from the VDP. I think the TurboCPU could still internally use its fast clock as required. --- Which I gather, is basically what you have effective.

Perhaps I have some design work to do this weekend.

Thanks Dean