This is totally correct, there is something not yet implemented in the core which prevents those games to run, I cannot recall what however.
So far, those games are only running under the RealCoco core
This is totally correct, there is something not yet implemented in the core which prevents those games to run, I cannot recall what however.
かすりん
Got it. Thank you
Been goofing with NitroOS9. It does seem to work, looks like some kind of Unix-like OS for the system. The VHD files with 6809 in the name seem to work if I pick CoCoSDC. The magic word is "DOS" -- type that in basic. The GIME versions come up in 80 columns. I don't think the mouse works? Anything that needs a mouse just gets stuck. TBH, I never had COCO3 ever, and this looks like a pretty deep rabbit hole.
No wait, I got the mouse working with 'Use Mouse for Rt Joystk' -- I thought that didn't work, but I poked at it again and now it's working. Maybe just user confusion.
The 6809 CPU had some nice facilities for multitasking, which weren't used by the base ROM. I'm pretty sure that's what NitroOS was about.
I've never used it, even in emulation, but I read about it somewhere, probably Wikipedia.
While it has been awhile, there is a new release from me... COCO3_20231023.rbf. Many changes and improvements to its overall functionality. Below is a list of changes but the highlights are - cycle accurate 6809 at up to 9.54Mhz - fix to Tom Mix Donkey King - Fix to obscure EOU OS9 bug - Fix to incorrect addressing of CARTs is full 32K ROM mode [Rampage and Pitfall carts work now]...
Detailed Changes:
CTF = Compile Time Feature...
What is next? Gary just sent me his next release... Hopeful integration soon...
-Stan
@rcade,
To be honest, I do not know if the core Coco3 needs more than 32Mb SDRAM as my Misters have 128Mb each, but are you sure that you do not have a [coco3.rom] inside your folder [bootrom].
I'm asking this because owning 2 Mister with 128Mb, I had the same issue, on one it was working and on the other one it wasn't (black/green screen).
While I was sure that the setup was the same, it wasn't, I had the coco3.rom in the bootrom on one SD card. Once I removed it, It worked w/o any issue.
かすりん
The coco3 core does not need more than 32M, however, since the core handles the sdram controller internally, the core would have to understand and make both modules work. I have 128MB and the SDRAM code I used was tailored around that. I do not have a 32M module at present and fixing this will likely be low on the fix list.
I am aware that a problem was introduced on the latest released version. Specifically, when switching to the text mode, it is often going to simi-graphics mode. This occurs in OS9 level1 games, OS9 level 2 with 32 character text ode screens, and some specific games like Contra. I'm presently working it identify the offending hardware code to fix this.
FYI,
-Stan
Just a FYI.....
This text is specific to the problem specified earlier with some OS9 builds which boot into semi-graphics mode. Presented here is why and a temp solution. A better solution is in the works.
The MiSTer CoCo3 project is a port of CoCo3FPGA for the DE1 board by Gary Becker. This is from the documentation:
The only Semi-graphics (SG) mode supported with the CoCo3 was SG4. CoCo3FPGA supports all the original Semi-graphics modes supported by the Color Computer 1 and 2. In most cases, software written using the Semi-Graphics will run with out any modification. The one caveat is SG6. On the CoCo3, the settings bit used to enable SG6 was re-tasked to enable lower case text. To get around this limitation, a switch on the DE-1 is used, SW5. If a program is run that uses the SG6 mode, turn on SW5. Because the original setting bit enables lower case text, any program written to run with SG6 can also display lower case text.
Here the documentation is a bit out of date. The switch referenced also is used to turn on artifacting (4 color mode in COCO hires). This switch is set by going into the 'Video Settings' and turning on 'Artifact Color: On - SG4'. This switch is normally set 'ON' and there are no issues. However, in specific COCO3 programs using lower case [some OS9 builds] it causes the SemiGraphics SG6 to be enabled and results in a non-readable screen.
FIX
The short term simple solution for the current release build is to set ''Artifact Color: Off - SG4''. This instantly fixes the graphics problem for the OS9 builds. Turn it back on for the 4 color hires modes. I know its a bit of a pain...
Normally I would go into both a documentation fix and work a better solution but Gary already has one coded. It removed the artifact enable from the config bit and greatly improves artifacts along with enabling them full time. The bit will be retained as a compatibility bit only. This is the present direction of the build.
-Stan
How did you realize that this was incorrect ? (was some software failing ?)
The 6809 is quite a popular CPU for arcades and other boards, so this change may be helpful to bring to other cores.
dshadoff,
Sorry for not responding earlier. This was largely a observed needed change. In early CoCo3FPGA timing, PH2 was generated from the master timing loop as roughly corresponding to the 6809 E clock. With the MiSTer implementation, we use the external SDRAM and as such a new signal - cpu_cycle_ena is delayed to meet those requirements and as such, the change was needed to be global and not just for RAM access.
Its not really something which will help anyone else.
Again, sorry for the delay...
-Stan
Release 20240514-004....
To Do...
This is mostly a maintenance release which adds cassette write capabilities.
-Stan