MiSTer FPGA Forum

Much as I love the console side of MiSTer, microcomputers are my main interest. I was making a little list for myself to see what's the status of various cores and decided to share it. It's in a proto-state, since I did not try all the cores yet myself and might've missed something in the ones I have. Hopefully others can chime in and improve it, so it's possible to have an instant overlook of the current situation (I can update the first post).

The idea is to mention the more important stuff, rather than some little things which need fixing. Things which could make cores more "complete" and closer to OG HW, in the sense of how C64 already had been before a lot of detailed recent improvements happened. It'd be also nice to know which cores are actively being worked on.

Cores which I think are "complete/mature": Amstrad CPC, C64, ZX Spectrum/Next, Amiga, Atari ST, TRS-80.
Please mention any crucial features which might be still missing for them, as well as for all the other microcomputer cores. Also, note that I'm aware that in few of these cases .vhd is used instead of tape/floppy functionality, yet it'd be nice to be able to use them as "real" computers.



ao486 - FPU, compatibility?, VGA output
Apple 2 - support 2 disk drives, write to floppy, floppy write-protect, other keyboard layouts?
Acorn Archimedes - ?
Acorn Atom - tape / floppy
Alice - video bug, WIP?
Atari 8-bit: 400/800 mode, tape
Amstrad PCW - HDD, SymbOS (not sure how important, see here)
BBC Micro - tape / floppy
Commodore 16/+4 - ?
Commodore PET - ?
Commodore VIC-20 - ?
CoCo/ Dragon 32 - CoCo lvl3, floppy - WIP
MacPlus - keyboard issues, accuracy (see here) - WIP
MSX - floppy / tape / cartridge, MSX1 port available elsewhere
ORIC - tape?, loading from disk also problematic
SAM Coupe - write?
Sharp MZ - ?, WIP?
TI/99 - tape, see here
X68000 - VGA, compatibility - WIP
ZX 81 - saving programs
--------------------------------

"tape" - means support for cassete dumps loaded from OSD
WIP - the core is being actively developed

This list is a work-in-progress. Latest update: 20-08-2021.

I could also be very interesting to have the Next186 SoC PC core ported to MISTer.
https://opencores.org/projects/next186_soc_pc

For sure, but I was thinking more about features of existing cores, than new cores. There's already a thread for that: viewtopic.php?f=29&t=2207

I know, I just mentioned it in regard of your mention of AO486 for which the FPU implementation seems unlikely. The Next186 does not use that much of the FPGA and adding a FPU coprocessor should be easier as far as FPGA space is concerned. It looks like no one mentioned it on the new cores wish list. I will.

The VIC-20 core could do with some love given to the C64 core, most of all automatically running loaded games, prg, cartridges etc. Cartridges often come in two parts, but it might be possible to figure out a way to auto-start them after both images have been loaded.

Why is the TRS-80 Model I listed there ?

The MiSTer MacPlus core has keyboard issues that make the latest build of the official core effectively unusable wherever the keyboard is required (there is a test build by alanswx from late March which mostly corrects this, but the latest official build remains broken). It has some minor but notable accuracy issues. Per gyruco/slingshot:

The audio crackings can be because the core is not cycle-exact: the video timings are not exactly the same, nor the contention because of concurrent access of the RAM by the video hardware and the CPU is not replicated.

It lacks gyurco's recently implemented Macintosh SE support from MiST, including the additional 2 SCSI slots. MiST's core now also can define 2 boot .vhd's, something we don't yet have on the MiSTer side.

Atari 8-bit core is not feature complete yet in my opinion as it is missing cassette tape image support. Another feature which would be welcome is true Atari 400/800 mode support. Currently the core operates internally only as a Atari 800 XL machine, even when selecting OS-A or OS-B system ROM. This breaks some software made with older models in mind and even holding the Option key on reboot does not eliminate all incompatibilities.

dshadoff wrote: ↑Wed Jun 30, 2021 6:21 pm Why is the TRS-80 Model I listed there ?

Because it's a MiSTer microcomputer core. If you meant to say that "the tape loading is working", or if you think it's overall pretty complete, then it's precisely the kind of feedback I'm looking for (I said this is a proto-list).

@meauxdal, TLPD-AVW: thanks, have updated the list. Regarding A400/800, sure, it'd be nice, though I have actually tried most (if not all) games from 1979-1981 era and I seem to recall they mostly worked. Can you remember any particular non-working ones?

akeley wrote: ↑Wed Jun 30, 2021 7:37 pm Regarding A400/800, sure, it'd be nice, though I have actually tried most (if not all) games from 1979-1981 era and I seem to recall they mostly worked. Can you remember any particular non-working ones?

I've been recently experimenting with games in .ATX format (accurate floppy dump with full data intact) from a romset sourced from Atari 8-bit Software Preservation Initiative. A couple of early Electronic Arts floppy releases like Archon and Pinball Construction set are marked there with "OS-B" postfix and indeed don't work on MiSTer's Atari 800 XL core. For example file "Archon (1983)(Electronic Arts)(US)[!][OS-B].atx" will display a friendly message on load. For those particular games that's a really moot point as later both game were updated with fixed compatibility and Archon was even published on cartridge years later, but I guess there must be less well known software titles which were stuck in 400/800 purgatory.

akeley wrote: ↑Wed Jun 30, 2021 7:37 pm

dshadoff wrote: ↑Wed Jun 30, 2021 6:21 pm Why is the TRS-80 Model I listed there ?

Because it's a MiSTer microcomputer core. If you meant to say that "the tape loading is working", or if you think it's overall pretty complete, then it's precisely the kind of feedback I'm looking for (I said this is a proto-list).

OK, here's a more complete summary of my TRS-80 thoughts, as a TRS-80 owner and one of the core authors (and somebody who has added ADC to a couple of cores):

1) I think TRS-80 is pretty complete. Disk images work, although only one format (the most common one; others are a tangled mess which are not straightforward to implement). Although, I don't recall whether it can write back to disk - which would be a feature that should exist. That should be verified.

2) Tape loading works, as long as we are talking about *.CAS files from the SDCard (it even loads them at turbo speeds if you like); I don't recall whether I put ADC input on this core, but I recall debating whether it was even worthwhile, since the tapes are quite problematic due to volume levels and obviously, decay. Pretty sure that tape audio output can be toggled though (it has been a while since I used the core, to be honest).

I transferred a significant number of old tapes last summer, after the core already existed - but I transferred via PC using Audiograbber and WAV2CAS software, to create CAS files (which I then verified). Trust me when I say that loading an old tape has never been fun - not back then, and especially not 40 years later. And even in this workflow which allowed intermediate hand-tweaking, I still had challenges. Direct load-to-core would be a nightmare.

If it doesn't already exist, it is possible to add ADC input for tape... but I'd want to understand what specific scenario would need this, to ensure that it's worth the effort. TRS-80 Model I is not a FSK-based system, so is more sensitive to various factors around the input sound (which I would prefer not to have to support).


If the point of this thread is to document the cores, perhaps it would be best to create Wiki pages which detail the capabilities and limitations of the cores, without making them sound like missing features or incompleteness. I'm sure in some cases, there were conscious decisions to implement the most frequently-used functions, and stay away from functions which could drag an author into a long discussion about how to use some feature that nobody likes in the first place.

Further, it would be really helpful on these wishlists to explain WHY you wish for these features, and what you would actually use it for.

dshadoff wrote: ↑Wed Jun 30, 2021 8:52 pm I think TRS-80 is pretty complete. Disk images work, although only one format (the most common one; others are a tangled mess which are not straightforward to implement). Although, I don't recall whether it can write back to disk - which would be a feature that should exist. That should be verified.

Thanks for the heads up on TRS (and developing it of course). It's one of my favourite micros, not sure why I've never got around to trying it yet ("T"is on the bottom, I guess...). I did have a quick go tonight and tapes/disks do load fine. Write-to-disk is indeed a "big" thing, so that would be something I had in mind making when making this list. Worth checking and eventually adding.

About ADC in general, I consider this a nice extra and so not something I thought about when writing the list. The "tape" mentioned in it means loading tape images from OSD.

dshadoff wrote: ↑Wed Jun 30, 2021 8:52 pm If the point of this thread is to document the cores, perhaps it would be best to create Wiki pages which detail the capabilities and limitations of the cores, without making them sound like missing features or incompleteness. I'm sure in some cases, there were conscious decisions to implement the most frequently-used functions, and stay away from functions which could drag an author into a long discussion about how to use some feature that nobody likes in the first place.

The main reason for this thread was just to have a quick snapshot of the state of the main features in regard to micro-cores available at a glance. Of course, any additional in-depth info below is hugely welcome. Updating the Wiki is another kettle of fish, definitely something which could benefit at least some of the pages.

It goes without saying that talking about it all is not meant in a depreciative way. I think most people understand that work on cores is not an instaneous process and that there are many difficulties along the way. I prefer to view this list from a glass half-full point of view myself, because the progress so far has been indeed very impressive.

dshadoff wrote: ↑Wed Jun 30, 2021 8:52 pm Further, it would be really helpful on these wishlists to explain WHY you wish for these features, and what you would actually use it for.

Well, it seems self-explanatory to me but ok, I perceive it on two levels:
- direct: most of the features mentioned so far are important for everyday use: write for saving programs/game progress, compatibility for greater access to software libraries, various bugs for usability. Stuff like tape/disk/cart functionality is crucial for those of us who'd like to pretend that we're using the actual machines the way how it was back then. As convenient as various vhd/hdf packs (such as MegaAGS) are, it can be great fun to do it the hard way too.

-meta: if we're aiming for 1:1 representation of real machines - in theory at least, of course - then every added feature contributes to this target. This can have an impact on the general "preservation" aim, as well as users' self-satisfaction of being closer to real hardware, at least closer than when using emulation.

Again, this list in no way meant as a "demand" or some such, but simply information gathering exercise. The state of most MiSTer cores is already extremely satisfactory, especially for a CRT user such as myself (there is no better device for that atm). But it's good to know what's going on, and also there is an added chance that aside from the core team of MiSTer devs, some accidental tourist might stumble by and contribute too, as it has happened recently with floppy for TI99 (thanks, @flandango).

akeley wrote: ↑Wed Jun 30, 2021 11:24 pm Write-to-disk is indeed a "big" thing, so that would be something I had in mind making when making this list. Worth checking and eventually adding.

Let me know what you find.

akeley wrote: ↑Wed Jun 30, 2021 11:24 pm

dshadoff wrote: ↑Wed Jun 30, 2021 8:52 pm If the point of this thread is to document the cores, perhaps it would be best to create Wiki pages which detail the capabilities and limitations of the cores, without making them sound like missing features or incompleteness. I'm sure in some cases, there were conscious decisions to implement the most frequently-used functions, and stay away from functions which could drag an author into a long discussion about how to use some feature that nobody likes in the first place.

The main reason for this thread was just to have a quick snapshot of the state of the main features in regard to micro-cores available at a glance. Of course, any additional in-depth info below is hugely welcome. Updating the Wiki is another kettle of fish, definitely something which could benefit at least some of the pages.

It goes without saying that talking about it all is not meant in a depreciative way. I think most people understand that work on cores is not an instaneous process and that there are many difficulties along the way. I prefer to view this list from a glass half-full point of view myself, because the progress so far has been indeed very impressive.

And I appreciate that. But with the number of times I see questions asked about cores' functionalities (even among developers), I think wiki pages should realisitically exist for the cores, which explain things which are commonly asked:
- features which are implemented
- features which are not yet implemented, but are intended
- known limitations/drawbacks/bugs
- overall compatibility (which is often not clear)
- how to use

akeley wrote: ↑Wed Jun 30, 2021 11:24 pm

dshadoff wrote: ↑Wed Jun 30, 2021 8:52 pm Further, it would be really helpful on these wishlists to explain WHY you wish for these features, and what you would actually use it for.

Well, it seems self-explanatory to me but ok, I perceive it on two levels:

I ask "WHY" for several reasons:

1) While you may have a clear sense of priorities (which are similar to what a developer would have), there are also people who ask for a feature merely because it once existed on one version of a machine at some point in history. Sure, if I was obsessed with a machine, I'd probably also seek this out... but I'm not seeing that based on the requests - I perceive that I am seeing people asking for things which they have no intention of personally using (or if so, for a few minutes only, just to see how it works).
-> In summary, to separate idle fantasy from actual requirement.

2) Secondly, there is a clear difference between, "I think it might be cool to load from from 40-year-old tape" versus "there is no other system or emulator which can do this, and I have treasured memories which I would like to digitize". Or, "there is a protection which exists requiring them to be loaded as audio files". This helps to set the priorities of millions of outstanding items.
-> Being clear about the purpose helps people on both sides to identify with each other's actual situation, and helps to prioritize on that basis.

3) Third, there is often A BETTER WAY to achieve the same goal, which will not drag the developer into a quagmire of issue-solving. The tape example above is such an example; I'm an original user, and could implement such a feature if it really was a benefit - but I didn't do so, because it's not the correct solution to the problem I had (reading old tapes to turn them into modern computer data). And I suppose that any original user of the TRS-80 Model I would rememebr how finicky the tape was... but that's not the average user of MiSTer; while the average user had *one* such computer, they certainly didn't have *all* such computers (and there are also some younger people here who didn't use them at all). I would prefer not be dragged through the nightmare of "you've got to get the volume levels right... no, exactly right... are you sure that's a Model I tape, and not a Model III ? A Level II BASIC machine ... ? ". Etc.
-> Being clear about specific usage helps to give better advice, and frees developers from being held captive by features which shouldn't have been implemented.


So, basically I'm just pointing out that developers aren't going to be persuaded to implement lists of features, but might examine something specific, if the use case was compelling. And that there is sometimes still confusion over whether some features already exist (which can ve solved through documentation).

Mac Plus core - CRT support. I mean, it originally came with a CRT built in.
Sharp MZ - Isn't this VGA only ? Why doesn't it work on a CRT ? It doesn't even work on an LCD via HDMI.
Acorn Atom - Again, what is the reason for no CRT support ? Have you even seen an Atom running on a modern display ? It looks ass.

Tape support is welcome in cores where the original machine had a tape drive. Not sure if ADC support is needed, when loading a cas from the OSD is much, much more reliable. And considering both get to the same end result, why bother with ADC ? It's just more wires and crap to connect up, and even then we don't have motor control, so useless on anything Commodore based.

And please, can we ditch the god-awful MMC crap ? The original BBC Micro didn't use MMC, it had proper disk support with a ADFS rom installed, or for a BBC Master, it was built in. MMC is such a convoluted, and crap way of trying games. Quite a few games still don't work with MMC, it would be so much better to use .ssd/.dsd images.

MiSTer_Kirk wrote: ↑Thu Jul 01, 2021 1:22 am Mac Plus core - CRT support. I mean, it originally came with a CRT built in.
Sharp MZ - Isn't this VGA only ? Why doesn't it work on a CRT ? It doesn't even work on an LCD via HDMI.
Acorn Atom - Again, what is the reason for no CRT support ? Have you even seen an Atom running on a modern display ? It looks ass.

MacPlus can be displayed on VGA CRTS, see here
Sharp MZ is WIP I think, wiki says HDMI support is coming.
Atom could use 15Khz, yes.

Overall, CRT support is lower-priority in MiSTer, since this project is HDMI oriented. Nevertheless, the updates are happening (eg Apple II), for which I am really grateful. The CRT issues might be worth a separate thread (I think Archie is one of the problematic ones).

I'd rather we not used an aggresive tone here - phrases such as "god-awful MMC crap" aren't really helping, even though I agree that it'd be great to see proper tape/floppy support for BBC (and few other machines).

Apologies for the tone, I just want to sell my original hardware, but it's looking increasingly likely I will have to keep it for a lot longer than I wanted.
I mean, if this project is trying to be as close to original hardware as possible, then surely equal priority should be given to the same capabilities the hardware was built for ?
I understand some like/want newer display tech, but since there is an analogue video port on the I/O board, then it would make sense to support it.

Also, the Archie does work on a CRT, I have mine working on my 15hz Philips monitor. I believe you need to set your monitor type as follows.

*Configure MonitorType Auto

Yes, The Macplus works on a VGA monitor, I had it running via VGA on my old PC VGA Monitor - but that has a flyback issue, so I'm stuck with 15hz CRT's, or my Dell 2007fb LCD - which looks terrible.

The analogue is being supported, most cores actually display fine on CRTs. For the others, we just have to be patient, that's the way with FPGA (especially seeing as the problematic cores are still WIP and/or are the less popular ones).

@dshadoff: regarding TRS-80, I've managed to make save games in couple of text adventures under Newdos/80, so I suppose the write support is ok. That would make this core prety much "complete" - it's amazing to be able to use it like the real machine. Though of course it'd be nice to see further improvements as well - I think wiki says that JV3 is "upcoming", also the lack of Caps Shift ability could be handy.

Do you know what the status of Alice/Coco/Dragon cores is? Are they WIP?

Alice/CoCo/Dragon cores are WIP... here's the rundown:
- cassette works fine, and ADC input has been implemented
- disk has NOT been implemented
- miniscule timing inconsistency which prevents double-speed mode on the SAM, so it isn't implemented - I want to fix this before looking at disk
- Dragon 64 has been attempted but backed out, since it isn't understood well enough to make it work properly
- Only implemented up to CoCo2 level, not CoCo3

akeley wrote: ↑Fri Jul 02, 2021 11:56 am I think wiki says that JV3 is "upcoming", also the lack of Caps Shift ability could be handy.

Steddyman implemented the disk access on TRS-80, so he's the one who would be able to speak to that (I haven't heard much from him since the winter though).

Could you explain what you mean by "Caps Shift" ? TRS-80 has a lot of eccentricities about it, and I'd like to understand specifically what you are talking about. Depending on what you talking about, this is likely not an issue.

@dshadoff
I just PMd you but it hasn't left my outbox.
Just wanted to share this file with you in regards to the Dragon64 issue you mentioned
http://dragon32.info/info/d64difs.html

Yes, we had seen that - @alanswx was working on the Dragon64 portion, but that document (and others) wasn't sufficient knowledge to get it to go. It seems we would need a developer more familiar with the machine (and/or a developer in possession of one).

dshadoff wrote: ↑Fri Jul 02, 2021 4:24 pm Alice/CoCo/Dragon cores are WIP... here's the rundown:

Sorry, I should correct something I said:
- my description was related to CoCo/Dragon
- Alice (related to MC-10) is a separate core, and was written by Pierco; he should be the one to comment on its completion status.

dshadoff wrote: ↑Fri Jul 02, 2021 5:50 pm Could you explain what you mean by "Caps Shift" ? TRS-80 has a lot of eccentricities about it, and I'd like to understand specifically what you are talking about. Depending on what you talking about, this is likely not an issue.

Sorry, I meant to say "Caps Lock" ability. Saw this as a github issue first and then when playing one of the Adams's games myself. But yes, it's indeed just a quirk: I looked it up and apparently Caps Shift+0 is how you enable Caps Lock. Guess it's one issue that can be closed or commented on.

In essence, the original TRS-80 didn't support lowercase... the video memory was missing one bit and the BASIC ROM forced all keyboard input to uppercase.
HOWEVER, there were modifications (add the missing bit to video memory), and alternative input methods (lowercase patches, etc.) to allow lowercase to happen.

I suppose what's at play in the Scott Adams adventures is that the software implemented its own keyboard routine, and checked whether the video RAM bit existed... implementing lowercase based on that check. Now that you mention it, back in those days, Shift-'0' was used by things like Scripsit as a caps-lock, so it probably became convention across other software. The original poster may not have been aware of this - or it may have been included in the instructions sheet for the game (which nobody ever reads).

I didn't investigate the bug report because at first I didn't understand what the person was talking about, and to be honest, I can't bring myself to play the Scott Adams adventures (they bored me to death back then... even though I had the patience to save data to cassette for 30 minutes at a time while developing code).

Thanks for finding the solution !

Does anyone know if someone is developing a FPU for the AO486 core?

Nobody is currently putting effort into that at this time. Space and timings are tight, and the amount of benefit versus effort is making it hard for developers to justify working on this rather than something else.

dshadoff wrote: ↑Fri Jul 09, 2021 4:30 pm Nobody is currently putting effort into that at this time. Space and timings are tight, and the amount of benefit versus effort is making it hard for developers to justify working on this rather than something else.

I thought Sorg said there is plenty room left on the FPGA. I understand implementing a FPU takes a lot of work. Was just wondering if anyone was looking into it. The AO486 core would be done with a FPU implemented. I’m sure we’ll see something in the future.

Also hoping someone will pick up the X68000 core.

X68000 is definitely getting some attention.

H6rdc0re wrote: ↑Fri Jul 09, 2021 9:06 pm ...
Also hoping someone will pick up the X68000 core.

See viewtopic.php?p=26448#p26448