mamedev
Commit for Foenix F256K retro-computer.
More information about the hardware is available here: https://wiki.f256foenix.com/
For the list of supported features, see: https://wiki.f256foenix.com/index.php?title=Emulation#MAME.
For ROMs, see the release page: https://github.com/dtremblay/mame/releases The ROM is called f256k.zip - there is also a SD Card image available there.
So... am I supposed to do something else to get this PR accepted? It seems to be stuck. The workflow hasn't been approved yet.
It sometimes takes a few days or weeks until a maintainer has time to look at PRs that aren't just a few lines or a new dump. The workflow did run and it seems it failed. Click the red X next to your latest commit above.
One overarching bit of feedback, it's usually not ideal to suggest that feedback be done via a Discord server. Part of the point of a pull request is that the code review occurs within the pull request itself.
While there is certainly a particular generational shift towards the use of Discord as a substitute for websites, that isn't something that tends to be shared by the wider software development community, at least those old enough to have been doing professional software development for the past couple of decades.
One overarching bit of feedback, it's usually not ideal to suggest that feedback be done via a Discord server. Part of the point of a pull request is that the code review occurs within the pull request itself.
While there is certainly a particular generational shift towards the use of Discord as a substitute for websites, that isn't something that tends to be shared by the wider software development community, at least those old enough to have been doing professional software development for the past couple of decades.
In my commit message, I state to report "defects" in Discord. I did not suggest to perform the PR work there. About generational comment: I think this is not warranted in a PR. And, I'm probably as old as you are if not older.
Out of sheer curiosity: how this driver behaves when testing? You are claiming that the driver is working, and by cursory glance I bet it really isn't.
Out of sheer curiosity: how this driver behaves when testing? You are claiming that the driver is working, and by cursory glance I bet it really isn't.
I'm not sure what you are basing your conclusion on. I wouldn't submit the PR if the system was not working. Maybe I misunderstand what you imply by "driver". I can give you a demo, if you like, via MS Teams or I could upload a video to YouTube. It works quite well on Windows, Linux and Mac - users in the community have tested this, not I.
You do need to have the ROMs of course (provided: here ). The ROMs include a disk operating system and SuperBASIC and other useful utilities. If a hard disk image is provided, applications can be loaded. The F256K machines have now been around for about two years and there are now new variants being manufactured now, for example with 65816 and 6809 processors (instead of 6502) and other sound chips.
I'm not sure what you are basing your conclusion on.
From your tendency of dismissing comments without actually doing anything. https://github.com/mamedev/mame/pull/14029#discussion_r2264050903 The driver is clearly not doing a logical to physical translation, and I can't see how a system that expects 512 KiB can work with a single page of 8 KiB, mapped on the same place on top.