doubling MSX core.

[sorgelig]

Existing 1chipMSX core is poorly maintained because there was no dedicated developer who understood MSX HW. It's also not convenient as it's ported from HPS-less design and requires VHD image. It also uses weird internal switch design. I'm ready to give it up in favor of your core. The only problem i see is lack of MSX2 support. Are you planning to add MSX2 HW?

[tdlabac]

I think a better concept would be another project following on from MSX2. However, I haven't thought about getting into MSX2 yet. I can also imagine the possibility of coming out of the MSX project and getting rid of the VHD image in favor of HPS. That might be a faster and more straightforward route.

[GuerreroNinja]

I support that, existing OCM core lacks I/O functionality (disk drive / cardtridges ports) that were present on real MSX, so @tdlabac core actually preserves the machines better and faithfully. Going MSX2 is the natural evolution of this core, as the main differences are the VDP and BIOS, as the core already support disk drives and the rest of the architecture. On the other hand, upgrading the existing OCM core fixing the problems it shows right now (lack of I/O control for disk drives and cartridges, memory mapping, BIOS, and such) maybe also an option.

[Vampier]

Here would be ideal solution:

• Expand the core to MSX2+ with MSX audio
• Have a ROMDB to identify the mappers (I have the data ready to go for 99.5% of the ROMS out there) at https://romdb.vampier.net/index.php so that the mapper can be auto detected
• Keep VHD support for people who still want to use the 'SD card' functionality and also for HDD converted games like Snatcher
• I recommend creating an MSX with 512KB (4096 if you really want this)

The openMSX team can always assist with explaining hardware and the IRC #openMSX channel can be found on Libera Chat. The code for the project also can be looked at (there are various other IRC MSX channels on Rizon as well)

The OCM core is written for the MSX FPGA hardware (One Chip MSX and various clones) and performs this role perfectly for that specific hardware. It has a role on the MiSTer until another core shows up. I've been an MSX user since 1984 as me anything ;)

[GuerreroNinja]

I think the first question here is: what I want to achieve? Preservation? Modern implementation? Functionality expanded? A fantasy computer?

The problem is, by my sole and humble point of view, OCM core does not achieve preservation of the original machine(s). At all. In fact, for me, OCM is some kind between fantasy computer and modern functionality, but no preservation as it lacks base funcionalities and adds new, modern ones. The OCM core was not created to preserve a machine, but to offer an attractive expansion/novelty to existing MSX power users. It has contaminated the FPGA core implementations, and until Molekula implemented a real MSX 1 core, we have nothing but that OCM monster (well, on others FPGAs like ZX-Uno, we have a MSX 1 core from Fabio Benaveluto but it is not finished at all and it is abandoned).

If the OCM core should be reused, beware loosing MSX1 compatibility, as it happens with OCM on many MSX 1 titles. In that case, a new core/project is recommended instead of turning this MSX 1 core into a MSX2+ one. Honestly, I don't like OCM core at all: being loadrom/loadcas/nonsense tools that stacks a lot of incompatibility layers on top of a modern controller is a no-no for me. In fact, if VHD and such are going to be used... then why a new development first place? Just stick to the OCM core then.

This MSX 1 core began as a new, fresh start on old hardware implementation, and my 2 cents here is to keep the same philosophy on a possible/future MSX 2 core: Preservation of real, original MSX hardware. That is, no VHD, no Nestor.sys, no new hacks and modern MSX tools, but a MSX2 simple, REAL implementation. For the modern developments (mainly VHD support), we already have the OCM.

But, as said, that is my 2 cents. The developer here has all the power to choose what he wants to achieve if further progression is done on this core or a new one.

[Vampier]

@GuerreroNinja you just made a case against the MSX community and also the Amiga core :) the MSX community has been a user driven community for the last 30 years ever since no new software and hardware was created on a commercial scale. The OCM was an official release by Mr Nishi himself to appease the community with official new hardware.

The current hardware like MFR/Carnivore/Carnivore2/GR8NET all have build in SD card capability for NESTOR. VHD has a real need in today's MSX world and should not be easily dismissed.

But if the core would to be developed beyond the MSX1 functionality (I really hope it will) VHD should not be the main focus. But the main focus probably should be on main functionality. Preferred would be the Panasonic FS-A1WX or Sony HB-F1XDJ.

[GuerreroNinja]

@vampier, I met personally Mr. Nishi long time ago, and have been a friend of Leonardo Padial for many years. And yes, I know personally Nestor Soriano, aka Konamiman (as you know he is Spanish and we met long time ago in a MSX users party). Don't take assumptions on me, like I am not into the MSX Community. I am not young nor naive. Don't take word for the entire MSX community and assume your point of view as the entire community point of view, I am really tired of that attitudes, both in MSX and Amiga worlds. Not all MSX people are MRC users with 1k+ messages on their profile.

Said that, I repeat myself: OCM is not a core that properly preserves the MSX machines. It was, as you said, something new for a community that demanded developments. SOME MSX power users want new machines, new developments, while other users like me want to preserve the old hardware properly.

The amazing thing is, despite the rather active MSX community, until now we had not a proper MSX 1 emulation/simulation. BlueMSX is a mess that are not properly synced at all (I developed a Black Frame Insertion solution for it, and that code was just awful). The result: you can't run 50Hz software synced. OpenMSX even don't sync vblank, so no 50Hz synced screens, aka tearings and stuterring all around.

And OCM is NOT a MSX 1 implementation. Until Molekula's core, we lacked a proper MSX 1 preservation... we even lack the basics.

Yes, I have 3 MSX2+ machines, MFR, and toys all around. I think this is not about who knows more, owns more, or who is the best Power MSX User of all time.

I think preservation should be a top priority. I am against using VHD and new implementations on preservation cores. A MSX 1 core who uses VHDs (hard disks) is not a MSX 1 core, it is a fantasy machine.

But I see you seek new developments, not preservation. Until we have a proper MSX 1 and MSX 2 real machines implemented without bells & whistles. Then we can talk about fantasy MSX machines all you want.

BTW: I never metioned the Minimig core at all. A core by the way that implements properly a basic A500, as it should. Not like the OCM one.

[Vampier]

Hey I never said you're not part of the MSX community :) nor did I want to turn this into a pissing contest as I think you read too far into my comments. I always try to stay respectful when communicating with MSX lovers as there is too much 'discord' in the scene anyway. The pictures I posted are examples of hardware that supports SD cards - not to show off my collection ;)

Back in 2003 I joined the openMSX team to preserve the software I played as kid - even though I'm not as active there as I used to be, but my goal hasn't changed (fun fact I spend over $15000 on that hobby without asking for anything in return.... ever)

MSX Software preservation is my personal goal / with MiSTer it's hardware preservation is the goal. My knowledge on how to turn an MSX into a mister core is non existent so I can only voice my opinion and wishes. For the rest it's up to the developer(s)

I laid out above what my preferences are and it doesn't mention anything beyond that (Panasonic FS-A1WX or Sony HB-F1XDJ) but the door to have options beyond that should be kept open and not slammed shut.

We now have a great MSX1 core which is exactly what a lot of MiSTer users have been asking for, most of the great MSX games are MSX1 games (Maze of Galious is still my all time favorite together with Penguin Adventure)

[vanfanel]

@Vampier It's your ill, elitist view of the MSX platform that made the MSX emulation and hardware scene the disaster it has been unril now. Look at the OCM core: in essence that is NOT an MSX computer at all, and many games fail (even patching loaders for the right slot configuration), others have broken audio, and a long, long etc. I have been using (should I say "suffering") the OCM core since it was first ported to the Altera DE-1 back in 2008 or so, and I wouldn't touch it anymore with a 10 mts pole since we have this MSX1 core which is a proper MSX1 machine with support for cartidges, floppies, etc

If it wasn't for Molekula's work, we would be swamped with the old, lacking, failing, bad-designed, poor-sounding OCM core based , yet you dare to come here to insist on your view to make it the same POS that the OCM core is? I will try to be polite: go back to MRC with your 1ChipMSX/TurboR ideas, enjoy your SofaRUN and other absurd pieces of software, and leave this wonderful project alone, it won't be transformed into the horrible likes of elitist TurboR-like OCM design or overengineered OpenMSX. Keep your hands away from this!

@tdlabac Please, do things the way you want. What you have done so far is INCREDIBLE: at long last, someone understood what an MSX1 is, and that was you. This is the first true preservation effort of the MSX hardware: OCM, OpenMSX, BlueMSX... they are all poor approximations for their own reasons. This core is simply an MSX1 computer: nothing less. Don't let the elitist TurboR-like view (VHD-based software loading, patches, loaders, etc...) pollute your clean view and objetives. Those Frankenstein/TurboR users have already ruined the MSX scene in other areas, don't let them do it here. MSX2 support woud be FANTASTIC, but an MSX2 is indeed a different computer (I guess MSX2 VDP could be lifted from the OCM core?).

[Vampier]

@vanfanel I was just talking about 'discord' int the MSX scene - and you come in swinging going straight for the jugular. Please read my post before your post as you probably didn't see that one yet.

[GuerreroNinja]

Keep calm people, we are just talking. Let's fight some other time :D.

I know a can be a bit aggressive when defending a simpler, standard approach on MSX emulation/simulation implementations, but believe me, this is needed in order to get "back to the basics", something I think we need desperately. MSX machines are failing due to age, we need to preserve them ASAP as they should.

And in order to properly preserve them, we need to implement the EXACT BEHAVIOUR they show when switched on. At least, as far as we can go. It is OK to simulate media using OSD or menus, but the video output and I/O operation of the machines should be respected.

Using modern hardware/software in cores is something that is fun and nice... when the basics are mature and well implemented. We can see that in C64 core for example, or even the Minimig core. That's nice.

What is not nice is implementing modern/advanced features without the basics properly done. This makes the development a pure mess and the preservation goes down the drain.

At the very end @tdlabac is the one and only that will choose how to approach this development, as we can't help him in that due to lacking FPGA coding skills. Let's try not to press him asking him too much. Step by step, easy going. Enjoy the very first, real MSX 1 core for now :)

[vanfanel]

@vanfanel I was just talking about 'discord' int the MSX scene - and you come in swinging going straight for the jugular. Please read my post before your post as you probably didn't see that one yet.

I will repeat myself: Take your FRANKENSTEIN-MSX absurd view elsewhere. We are talking about true MSX implementations here. I have read everything you wrote and I know what you're trying to get. No way, man. No way.

[GuerreroNinja]

BTW... @vanfanel had one of the very first units sold of 1ChipMSX, he knows well what he is talking about. And then the Zenmix... I think it was 2008.

[vanfanel]

BTW... @vanfanel had one of the very first units sold of 1ChipMSX, he knows well what he is talking about. And then the Zenmix... I think it was 2008.

Indeed, I have been suffering the OCM core since 2008 or so (not in 1ChipMSX, but in the Altera DE1 and later the Neo Zemmix), I know it's sad limits caused precisely by implementing "extra" hardware without the basics being completely right.

[Vampier]

@vanfanel your opinion about me is noted: other than that EVERYTHING I wrote above indicates that I agree with you.

@GuerreroNinja I know who you guys are :) I never said anything bad about the 2 of you

Let me now clearly state my opinion in simple terms:

• The current MSX1 core is amazing directly loading ROMS/Disk is something the MiSTer community has been asking for. This core fills this gap and I've been using @tdlabac's core since version 2 or something.
• My wish is for an MSX2/MSX2+ core to be a reality one day if @tdlabac (maybe with some help from the MiSTer community?) feel like it.
• OPTIONAL<<< memory expansions and or SD card drivers (thought VHD) would be nice to have but should not be a priority.

[vanfanel]

@Vampier Ok, Now it's clear. I was a bit harsh before, because I have been many years waiting for something like Molekula's core, so I fear it could be transformed into the OCM abomination, that's all :) But we are all MSX lovers and we shouldn't really take our discussions too seriously! I TOTALLY agree with your latest post, it was a pleasure to be wrong this time: it seems we share the same view. My respects, sir. Sorry for my earlier tone!

[Vampier]

@vanfanel :) it's all good - I hope you also enjoy openMSX :)

[GuerreroNinja]

It is a pity I can't help coding for this project, I would love to so I could help with something more useful than words. When looking other 8 bit cores, I was jealous. Why we can't have a MSX 1 core? A well known machine, sold by millions all over the world... and now we have a GREAT MSX 1 core as it should.

And all over those years, people that don't know the MSX computers said the same: MSX? We already have a core for the Mister, we have the Zenmix... they were not MSX users, so they just launched Sofarun or the MSXPACKS and play like a NES console. Most users didn't even know how to load a game, how to type RUN"CAS: or BLOAD"CAS:",r because, well, they have the nice Sofarun they didn't need to actually know shit about MSX. Even the very basics.

This is what OCM brought us to the scene: for a lot of non-MSX users, turned MSX into a dumb console that does not represent an actual MSX. Perhaps for power users it is nice to have MSX-DOS, a hard drive and tons of RAM, MSX-Audio and toys, but for new people, for MSX base users, it is a complete disaster. It is a bit understable that I hate it, a lot. It serves as a parasite that blocks proper developments. It served its purpose long time ago, now it is time to bury it.

[Vampier]

@GuerreroNinja you can help with the core by testing and providing feedback - I'm not sure there is a test suite to compare timings with real hardware and emulators but that could be used here as well (maybe SD snatchers acid test?). I've been testing some DVIK/JoyRex demos (Waves for example) to see some timing issues. I can tell that all Konami games are flawless.

[tdlabac]

I don't want this post to sound like a promise that I'll get into MSX2/MSX2+. For now, I'm considering and gathering my materials. I've never owned an MSX, but as a kid I admired it for the ability to run some games on a Sord M5

But I would like to reiterate my belief that adding MSX2/MSX2+ support to MSX1 is the wrong way to go. Granted, the standards are very similar, but this is a different computer. Another advantage of splitting into two projects may be for users without SDRAM. Though limited, but you can still run the core without SDRAM. And the last reason is that the HW design will stick to the specific machine.

Maybe there will be reasons I don't see that will show me another way, a better solution.

[GuerreroNinja]

Yes, I also think that two separate projects is the way to go in order to keep the cores clean. Specially for MSX2, it is VERY important to keep separated core bugs from incompatibilities, so I think it will be easier to spot problems if both cores are totally separated.

[Kitrinx]

the two systems are practically identical, why should the be separate? It will almost ensure that their code gets out of sync and more difficult to maintain.

[Kitrinx]

To elaborate on this: -Same CPU for MSX, MSX2, TurboR (This is minorly different but it's included in T80 which is already used) -Same sound chip in all three basically, since you're already using the jotego chip in MSX1 -Same peripherals, including disk drive, tapes, and carts, though the former two are mostly in later models -RAM is quite easy to change the size of since it's memory mapped

The only really major difference is the (backwards compatible) VDP in the MSX2+

[wwark]

VDPs accross MSX, MSX2, MSX2+ and Turbo R have some color differences. If at the end all is integrated on the core, i think it is important to have an option to change VDP (MSX1, MSX2, MSX2+) to be able to play content MSX1 with the VDP of MSX1 Videos below: https://m.youtube.com/watch?v=dbH-xg4gj0M https://www.youtube.com/watch?v=BmXWR9kWvhs

[Kitrinx]

There's so much space it's realistic to simply have two separate vdp chips (you could just yoink the one from the old core) and use both with a chip enable based on system selected

[tdlabac]

There's so much space it's realistic to simply have two separate vdp chips (you could just yoink the one from the old core) and use both with a chip enable based on system selected

At that point, we're creating a supercomputer, not a replica.

[GuerreroNinja]

Memory mapping, BIOS and VDP differences make MSX 2 computers to have some trouble when running some MSX 1 titles, specially european cassette based ones. Some are due to poor coding (like hardcoding the memory mapping of an MSX 1), but nevertheless they just don't run. Using a single core for both computers can be beneficial, but the memory mapping, the BIOS and the VDP should have some kind of switch system that may be difficult to implement (as I said, I am no FPGA coder so I don't know how hard this may be). Besides, this approach resembles an emulator instead of a machine implementation...

The advantages and disadvantages for each approach (single core for MSX 1 and MSX2 or dual cores, one for each machine) are something @tdlabac will know better than me for sure.

[Kitrinx]

While my expertise is not in MSX specifically, I've written enough cores to be confident in saying that maintaining a single codebase for the relatively small differences, even if there is additional discreet chips, is the wise move. Otherwise every fix to disk drives, or common cart mappers, or any of the other (many) shared components would have to be distributed to each and re-released. It's double the maintenance for no effective gain.

[birdybro]

I have to agree with Kitrinx here. If they all used the same VDP, but there are only color differences, then just having conditionals for the palette swap based on an OSD switch for the VDP type is more than sufficient. I did this in the SMS core, but for .sg extension for SG-1000 games for instance:

https://github.com/MiSTer-devel/SMS_MiSTer/commit/7ec42c2dcf7f92d9cada2f08c115bc4dd3a74c3a

It doesn't require a whole other core. Like Kitrinx says, if it needs two VDPs and you swap between them when you select using a different system, that is definitely doable and better.

@GuerreroNinja The concept being suggested by having it in one core isn't so that all MSX1 games would be ran as if an MSX2 was running them. It would be like having a magic toggle switch where your MSX1 transforms into an MSX2/TurboR at the blink of an eye, meaning all of the requirements of one system go tto the other. You change the system, it sends the same reset signal that's in the OSD as the "Reset" button (similar to the Genesis core's region swap).

[GuerreroNinja]

@GuerreroNinja The concept being suggested by having it in one core isn't so that all MSX1 games would be ran as if an MSX2 was running them. It would be like having a magic toggle switch where your MSX1 transforms into an MSX2/TurboR at the blink of an eye, meaning all of the requirements of one system go tto the other. You change the system, it sends the same reset signal that's in the OSD as the "Reset" button (similar to the Genesis core's region swap).

Well, the core as today is really flexible as we can choose the BIOS (main, sub and disk) and MSX model to run. I don't know how tdlabac implemented it, as I am not a core developer myself and my knowledge about the it is quite limited, but I find it very usable. In fact, I have not opened any issue lately as I have not faced any. I suppose both logic elements related to MSX1 and MSX2 are implemented and you switch one or other in OSD, which reset the machine when you change it.

[birdybro]

Yes, it's all working out fine so far :)

[tdlabac]

The current version I'm working on assumes that a set of ROMs will be loaded that already contains configuration information. However, this means that it is no longer a "replica" of a specific computer, but rather a hardware emulation of the MSX platform. However, this is not necessarily a disadvantage. This is how it works.

[GuerreroNinja]

The current version I'm working on assumes that a set of ROMs will be loaded that already contains configuration information. However, this means that it is no longer a "replica" of a specific computer, but rather a hardware emulation of the MSX platform. However, this is not necessarily a disadvantage. This is how it works.

I see, is it like OpenMSX? That is, there is configuration file that describes the ROMs used and the slots of the machine, then applies them to the core and launch it?

[tdlabac]

I see, it's like OpenMSX? That is, there is configuration file that describes the ROMs used and the slots of the machine, then applies them to the core and launch it?

Approximately, yes. Definitions describing what ROM to use and what slot to put it in, how much memory and how to access it, a table for converting keyboard capture codes to MSX hardware, and the MSX type will be freely available. The SW utility will then go through these definitions, and if it finds all the ROMs it needs, it will create a package for that machine that can be easily loaded using the OSD.

[GuerreroNinja]

I see, it's like OpenMSX? That is, there is configuration file that describes the ROMs used and the slots of the machine, then applies them to the core and launch it?

Approximately, yes. Definitions describing what ROM to use and what slot to put it in, how much memory and how to access it, a table for converting keyboard capture codes to MSX hardware, and the MSX type will be freely available. The SW utility will then go through these definitions, and if it finds all the ROMs it needs, it will create a package for that machine that can be easily loaded using the OSD.

Wow impressive!! It is indeed a superb feature that overcomes any compatibility issues that plagued the MSX standard and encapsulates the slots and ROMs config, something most users will find really useful.

[birdybro]

Thanks for all the hard work Tomáš!