Cool. Let's call it alpha then, progressing to beta 😀.

JAL

I've been working on XTIDE support. This will allow me to ship with a working hard drive out of the box, which will be nice, as everyone seems to find configuring MartyPC for a hard drive to be difficult.

I've barely implemented enough ATA registers for basic functionality, but it's good enough for reading disks so I threw it up on https://martypc.net if you want to play with it.

Another new feature: memory editing, at last.

People were often bewildered how I got this far without being able to edit memory. Hey, it just never came up. Sure, I wanted to a few times, but I just worked around it 😁

Double-clicking on a cell enters edit mode, and the edit box will move from cell to cell as you enter hex codes. Here i've tweaked some of the attribute bytes in VRAM to make the DOS prompt all pretty.

Ah, editing VRAM. Are you then also planning to allow editing internal registers? So I can edit all 4 planes of EGA? 😄

jal wrote on 2025-03-03, 10:02:

Ah, editing VRAM. Are you then also planning to allow editing internal registers? So I can edit all 4 planes of EGA? 😄

You can edit CPU registers. I'd like to add editing CRTC registers as well.

I'm still not sure what to do about planar VRAM. You can edit the VRAM window, but it is from the CPU's perspective, so the active write mode will apply to whatever you edit 😁

Yeah, that's why I want to change the EGA registers 😁 (I'll probably never use it tbh, but planar mode was the first thing that came to mind.)

jal wrote on 2025-03-03, 19:29:

Yeah, that's why I want to change the EGA registers 😁 (I'll probably never use it tbh, but planar mode was the first thing that came to mind.)

I'm thinking of some sort of system where MMIO devices can register an arbitrary number of planes, and then adding raw access methods to the mmio device trait. Then we can list these regions as separate address spaces in the memory viewer, accessible via dropdown. You could view the 2MB on the EMS card that way as well

I added Disney Sound Source and SN76489 emulation, and a cute lil oscilloscope viewer for the latter.

https://youtu.be/QkxBRmgNTjU

Cool, what emulator cores did you use for those? And can we expect AdLib and SB in the future? 😁 (Or GameBlaster 😁)

jal wrote on 2025-03-25, 07:14:

Cool, what emulator cores did you use for those? And can we expect AdLib and SB in the future? 😁 (Or GameBlaster 😁)

They are my own implementations at the moment. Adlib is already present via nuked-opl. Sound Blaster is a logical next target.

GloriousCow wrote on 2025-03-25, 13:55:

jal wrote on 2025-03-25, 07:14:

Cool, what emulator cores did you use for those? And can we expect AdLib and SB in the future? 😁 (Or GameBlaster 😁)

They are my own implementations at the moment. Adlib is already present via nuked-opl. Sound Blaster is a logical next target.

Wrt Adlib, I have a thread related to reverse-engineering it here somewhere.
It's basically a cycle-accurate emulation, except CPU interface timings of course (it's read/write slowness of the I/O ports isn't emulated much). The audio generation is cycle-accurate, with all known sound generation based on reverse engineering the YM3812 chip.
See:
My Adlib thread: Can anyone help me fix my Adlib(OPL2) emulation?
Reverse engineering reports: https://yehar.com/blog/?p=665
My implementation of it (although one Dosbox-based effect added in (vibrato or tremolo I think), due to unknown behaviour of the real chip so far): https://bitbucket.org/superfury/unipcemu/src/ … ardware/adlib.c
I think it was the part based on fnum, sticking out like a sore thumb because of not using the integer math, from what I remember.

superfury wrote on 2025-03-25, 21:19:

Wrt Adlib, I have a thread related to reverse-engineering it here somewhere. It's basically a cycle-accurate emulation, except C […]
Show full quote

Wrt Adlib, I have a thread related to reverse-engineering it here somewhere.
It's basically a cycle-accurate emulation, except CPU interface timings of course (it's read/write slowness of the I/O ports isn't emulated much). The audio generation is cycle-accurate, with all known sound generation based on reverse engineering the YM3812 chip.
See:
My Adlib thread: Can anyone help me fix my Adlib(OPL2) emulation?
Reverse engineering reports: https://yehar.com/blog/?p=665

That's impressive and you should be very proud of your work. I am mostly satisfied with nuked-opl, as I do not have the time to devote to investigate OPL2 emulation at the level you and nukey have, and I doubt I can advance the state of the art in any meaningful way. I note that your code is GPL3, which unfortunately precludes me from using any of it.

GloriousCow wrote on 2025-03-25, 21:35:

superfury wrote on 2025-03-25, 21:19:

Wrt Adlib, I have a thread related to reverse-engineering it here somewhere. It's basically a cycle-accurate emulation, except C […]
Show full quote

Wrt Adlib, I have a thread related to reverse-engineering it here somewhere.
It's basically a cycle-accurate emulation, except CPU interface timings of course (it's read/write slowness of the I/O ports isn't emulated much). The audio generation is cycle-accurate, with all known sound generation based on reverse engineering the YM3812 chip.
See:
My Adlib thread: Can anyone help me fix my Adlib(OPL2) emulation?
Reverse engineering reports: https://yehar.com/blog/?p=665

That's impressive and you should be very proud of your work. I am mostly satisfied with nuked-opl, as I do not have the time to devote to investigate OPL2 emulation at the level you and nukey have, and I doubt I can advance the state of the art in any meaningful way. I note that your code is GPL3, which unfortunately precludes me from using any of it.

At least the documentation it's based on is available. Also it's written in plain C (no, not c++). Which can't be used in your project anyways, as it's in Rust afaik?
It can however give some hints as to how the chip rendering works at least?
And my thread and the reverse engineering info can help a lot too. Combined, a treasure trove of OPL2 emulation information and how it works.

It's one of the things I'm actually proud of in my emulator, as I've made the only cycle-accurate OPL2 rendering chip that exists at the moment. At least I don't know of other chip-accurate implementations (with the actual LUTs and mechanics of the real chip). The only thing that's obviously inaccurate is the vibrato (that's the effect I copied from Dosbox, due to missing reverse engineering of the original chip for that effect), and the slow I/O ports (waitstates) of it's I/O.

I originally started with fake86's implementation, but eventually converted the whole thing, rebuilding it entirely to my own code based on reverse-engineering findings of other people (like the one mentioned in my last post).

The other thing is my implementation of a full SF2-based MIDI synth built right into my emulator. Although there are some odd volume problems with some intruments somehow. I can't seem to find out what's going wrong there.
It's also quite heavy on the CPU, right now taking 128 audio channels to rendder (half optimized away with mono samples with my latest changes, split left/right are still heavy, mainly due to reverb effects and lots of floating point and audio filtering, which sound pretty amazing with proper low-pass effects applied dynamically through time (modulation envelope)).

I think that rather than on the output side, the volume issues might be due to the modulator setup though (and it's linking of modulators perhaps) as only some instruments seem to be affected.

GloriousCow wrote on 2025-03-25, 13:55:

They are my own implementations at the moment. Adlib is already present via nuked-opl. Sound Blaster is a logical next target.

Ah, I forgot you already had OPL. Are you also going to support full Tandy/PCJr emulation, since you have Tandy/PCJr sound now?

JAL

jal wrote on 2025-03-26, 14:01:

Ah, I forgot you already had OPL. Are you also going to support full Tandy/PCJr emulation, since you have Tandy/PCJr sound now?

You've got it backwards. I've had support for Tandy 1000/PCjr already except for sound.

I've added jr-IDE emulation to give the PCjr a hard drive, and implemented light pen support for the IBM PC with CGA, Tandy 1000 and PCjr

GloriousCow wrote on 2023-06-30, 01:44:

MartyPC is a cycle accurate IBM PC/XT emulator written in Rust with an emphasis on realtime visual debugging features. […]
Show full quote

MartyPC is a cycle accurate IBM PC/XT emulator written in Rust with an emphasis on realtime visual debugging features.

Github
https://github.com/dbalsom/martypc

Video Demo
https://www.youtube.com/watch?v=zADeLm9g0Zg

Web Demos
8088MPH: https://dbalsom.github.io/martypc/web/player. … l?title=8088mph
Area 5150: https://dbalsom.github.io/martypc/web/player. … ?title=area5150
CGACOMP: https://dbalsom.github.io/martypc/web/player. … l?title=cgacomp
FreeDos: https://dbalsom.github.io/martypc/web/player. … l?title=freedos

Current release (0.1.2)
https://github.com/dbalsom/martypc/releases/tag/0.1.2

I'm eager to hear any feedback, suggestions and bug reports people might have.

MANI wrote on 2025-04-21, 11:24:

GloriousCow wrote on 2023-06-30, 01:44:

MartyPC is a cycle accurate IBM PC/XT emulator written in Rust with an emphasis on realtime visual debugging features.

Er, did you mean to post something?

Perhaps look into dual SAA1099 (game blaster, and compatibles like Sound Blaster (pre 2.0 that is). It's pretty much a hard panned left/right dual chip setup (one for left, other for right). It uses PWM for sound generation (applying volume). UniPCemu's started as a Dosbox clone, but I added high frequency PWM into it for accuracy (ofc low-pass filtered to output from the documented chip frequency (8MHz I think, don't remember)).

superfury wrote on 2025-04-21, 22:14:

Perhaps look into dual SAA1099 (game blaster, and compatibles like Sound Blaster (pre 2.0 that is). It's pretty much a hard panned left/right dual chip setup (one for left, other for right). It uses PWM for sound generation (applying volume). UniPCemu's started as a Dosbox clone, but I added high frequency PWM into it for accuracy (ofc low-pass filtered to output from the documented chip frequency (8MHz I think, don't remember)).

I'd like to do Soundblaster 1.5 or 2.0 or something more widely supported first, but I can look into that.