So in 8080 mode, the default stack segment is changed to DS instead of SS?

The documentation for CALLN literally says:

SP <- PS - 6
MD <- 1

That's directly after writing the PSW,PC and then PC on the stack using SP.
Is that 'PS' a typo? From what I gather, 'PS' is actually the CS register? It wouldn't make sense to point SP to 6 below CS, as they're different kind of variables(SP being an offset, CS being a segment)?

jal wrote on 2025-05-20, 09:01:

Well, that's a choice 😀. I would definitely show the 8080 register names as well.

I feel like I spend a lot of time on features nobody will ever use for the half-dozen people who might actually use MartyPC for anything, so its a cost/benefit analysis. This is a niche feature in a niche emulator, so you may need to excuse some rough edges. If you are personally planning to use this and want 8080 register names, I'm listening. If it's just an opinion about what a hypothetical user might prefer - well, there's a terribly long list of other things that need doing, if you feel me 😀

superfury wrote on 2025-05-20, 20:02:

The documentation for CALLN literally says: […]
Show full quote

The documentation for CALLN literally says:

SP <- PS - 6
MD <- 1

That's directly after writing the PSW,PC and then PC on the stack using SP.
Is that 'PS' a typo? From what I gather, 'PS' is actually the CS register? It wouldn't make sense to point SP to 6 below CS, as they're different kind of variables(SP being an offset, CS being a segment)?

It's a typo.

DaveDDS wrote on 2025-05-19, 21:36:

So what exactly do you have to do to run this thing?

I7/8G running Win7-64 PRO, I unpack MartyPC_win64_0_4_0_20250511.ZIP
into R:\MartyPC (R: is a 1G RamDrive on my systemn - where I test things)

This would usually be the point where I will tell you you're running Windows 7, an obsolete operating system, and I don't support it.
But this is your lucky day because another one of you Windows 7 holdouts actually went to the trouble of helping me set up a Windows 7 build.

Go here:
https://github.com/dbalsom/martypc/actions/runs/14961542911

Click on 'martypc-windows7-gha' at the bottom. I do not support this version, but maybe it will work for you.

Unfortunately, if the hardware you're running this on is the same hardware you had when Windows 7 was relevant, MartyPC won't run well at all, but let me know how it goes.

GloriousCow wrote on 2025-05-20, 19:36:

The elephant breakdancing effect uses a similar concept, since we have areas where there's just a magenta background: […]
Show full quote

The elephant breakdancing effect uses a similar concept, since we have areas where there's just a magenta background:

The attachment elephant_spoiler.png is no longer available

You can see that things in VRAM don't even have to be in the same order as how they are drawn on screen. Being in control of the start address at all times is very powerful!
I'd imagine this is done to avoid having to switch back and forth between the text-drawing code and the elephant-drawing code twice. If we keep all the text at the bottom then there's only one switch needed.

Ha, I don't remember exactly why it's laid out that way - likely it was to avoid changing things too much after the scroller. That part uses *more* VRAM than what is visible (four strip-like "pages"), so the frame and memory structures are more constrained.

DaveDDS wrote on 2025-05-19, 21:36:

If I run: martypc_launcher.exe It comes up with a settings menu, I set: - Machine type set to: XT-IDE - Floppy disk 0 (A:) set t […]
Show full quote

If I run: martypc_launcher.exe
It comes up with a settings menu, I set:
- Machine type set to: XT-IDE
- Floppy disk 0 (A:) set to "R:\A"
-- I've tries this with a bootable MS-DOS 5.0 (1.44m image) [not XTish]
-- and Bootable MS-DOS 2.11 (360k image) [should be fine in XT]
-- both of which boot fine in DBDOS
- Click "Run"
=same error as above= then (when I OK):
"(I) Success!"
-- This happens with the default C: "default_xtide.vhd"
-- But if I go in and manually select: R:\MartyPC\media\hdds\default_xtide.vhd
-- sometimes I don't get the error, but still "Success" and no further.

The first thing to do is just to run martypc.exe and if that doesn't work there is no step #2 except to figure out why - in this case you probably need a specific Windows 7 build.

The release is set up out of the box to boot an IBM 5160 machine with GLaBIOS and XT-IDE, mount the included VHD and boot to a C prompt with no intervention, no ROM downloading, or anything else required from the user. You can mount floppies and such from the GUI after you've started it. I recommend putting your floppy disk images in /media/floppies as MartyPC creates a very handy quick-access menu for selecting them if they're in there. You can browse to them elsewhere, of course..

Take a look at martypc.toml, TOML is sort of an advanced INI file. There's lots of things you can configure in there.

The broken link in the launcher should go here: https://github.com/dbalsom/martypc/wiki where I have some documentation still in progress. One thing I need to document better are the various command line options.

GloriousCow wrote on 2025-05-20, 19:51:

For a good reason. We're emulating 40 column mode in 80 column mode, drawing glyphs with the same glyph wouldn't look right.

EDIT: VileR beat me to it 😁

Now I realized that the blinking cursor for the 40-column mode there is not real.

VileR wrote on 2025-05-20, 19:49:

That's because we're simulating 40-column text, but the actual mode uses 80-column character timings, so the first scanline we actually use can't be taken from the same glyph. One fake 'character' is two real characters across, so each of its scanlines is composed of (typically) two different glyphs next to each other.

I had already done such a test - it turned out that you can't reproduce all full-height 80-column characters that way, but you *can* reproduce all (or most) 40-column characters, and that's why I picked that scheme for the intro. Always subvert expectations. 😉

Got it, thanks.
I was confused by the fake cursor for 40-column mode.

GloriousCow wrote on 2025-05-20, 21:21:

... This would usually be the point where I will tell you you're running
Windows 7, an obsolete operating system, and I don't support it. ...

Sigh, looks like I'll have to develop my own after all...
There's several things about Win10 that I don't particularly like, I'm retired
now and pretty much use only my own software on a daily basis... (and yes, I do
have a couple Win10 systems for those cases where I do want to run someone
elses "stuff" and its devs felt the need to block Win7 (I personally have
developed lots of Win32 applications that run just fine on Win7 or Win10)

And... I have to say that with 90 files and consuming 70MB, MartyPC might be
more complex than I'd like. For now I'll continue to use DBDOS...
I'm using an ancient version of DosBox - about 6 files, 2.5MB (and runs
fine in Win7 or Win10)...

To give you an idea of what I like for "simple"... have a look at DVM (Daves
Virtual Machine) on my site. This implements a processor I invented a number
of years ago called C-FLEA - a tiny CPU (the core is implemented in about 200
lines of C without any library references) which happens to be a fairly ideal
target for my C compiler.

I actually made it to support my C compiler on tiny embedded processors which
were not suitable candidates for a native port. It's NOT x86... but I decided
to implement it for Win64 ... and it implements almost all of my C library as
single instructions, so it basically has all of the DOS functions I use....

Much of the "stuff" I'd written in last 40+ years using my own compiler, ran
under DOS, I can "port" to Win32/64 just by recompiling for C-FLEA/DVM.

Unlike other DOS VMs a .DVM application runs on (will full access to) the host.
So for example, my EDT editor (which I use a lot - using it to enter this msg
offline): EDT.C

DOS> cc edt -pof m=s
Creates 12k EDT.EXE which runs under DOS : EDT file

WIN> DVM CC m=s
Creates 8k EDT.DVM which runs under windows : DVM EDT file

Btw, DVM.EXE is about 15k (to be fair it's compressed - so nearly 30k real
code), does not require any .DLLs or other support files. Does not have to be
"installed" etc... You literally just run: DVM program-name [arguments]

I've implemented DVM for Windows, Linux and a few more obscure targets... this
lets me easily run a lot of my "stuff" anywhere I care to port DVM to.

But it does have limitations, any of my code which contains inline assembly
obviously can't be moved to C-FLEA without a lot of rework... and I can't "test
stuff" on variations of x86... Now I just have to decide if it's worth it to me
to software implement those x86 variants.

Btw, No intense offended ... I guess I am just in a "rant about modern software development practices" mood 😀

GloriousCow wrote on 2025-05-20, 21:21:

...But this is your lucky day because another one of you Windows 7 holdouts actually went to the trouble of helping me set up a […]
Show full quote

...But this is your lucky day because another one of you Windows 7 holdouts actually went to the trouble of helping me set up a Windows 7 build.
Go here:
https://github.com/dbalsom/martypc/actions/runs/14961542911
Click on 'martypc-windows7-gha' at the bottom. I do not support this version, but maybe it will work for you.

Sorry, I'm not really familiar with "github" ... I can see that file at the bottom (even with it's size) but it's not obviously clickable?

jal wrote on 2025-05-20, 15:51:

DaveDDS wrote on 2025-05-20, 14:23:

I don't have much experience with the V20, but I have a LOT of experience with the 8080. My first computers was a homebuilt 8080 […]
Show full quote

I don't have much experience with the V20, but I have a LOT of experience with the 8080.
My first computers was a homebuilt 8080 based machine, my first "commercial" one was an
Altair8800 - we're talking mid70's here, and I wrote a LOT of 8080 code incl 8080 assemblers,
debuggers, BASIC interpreter, C-compiler, my own OS, lots of tools/utilities and a couple of
simulators/emulators for it.

That's pretty cool. Did you also program for the Z80?

Not nearly as much - I wrote an assembler for it at one point, wasn't super keen on the syntax they used for some
of the instructions...

And I didn't actually have one in my main system (the Altair) and never found a good enough reason to non-standardize
the machine by building a custom CPU card.

After the 8080, I went mainly to the 6809 and never really looked back (till the x86 because
what everyone had)

GloriousCow wrote on 2025-05-20, 22:01:

... The broken link in the launcher should go here: https://github.com/dbalsom/martypc/wiki where I have some documentation still in progress. One thing I need to document better are the various command line options.

Any reason you can't just put the help information in the distribution?

I'm a guy who when I find something I like, tends to use it for "years". It's frustrating when at some point
you want to do something "a little different" and want to refer to the docs, only to find that the server/page
is "long gone"(or now references a not-quite-completely-unlike newer version)

DaveDDS wrote on Yesterday, 01:12:

Sorry, I'm not really familiar with "github" ... I can see that file at the bottom (even with it's size) but it's not obviously clickable?

Unfortunately you need to be logged into Github to download artifacts. If there's some other way I can get the file to you, let me know. I'm guessing that if you don't have a Github account you probably don't use Discord either.

DaveDDS wrote on Yesterday, 01:27:

Any reason you can't just put the help information in the distribution? […]
Show full quote

Any reason you can't just put the help information in the distribution?

I'm a guy who when I find something I like, tends to use it for "years". It's frustrating when at some point
you want to do something "a little different" and want to refer to the docs, only to find that the server/page
is "long gone"(or now references a not-quite-completely-unlike newer version)

You raise a good point. I have struggled with wanting to document some new feature, only to realize I'd be overwriting information that applies to the current version, leading to confusion. In this sense the Github wiki is not ideal.
Going forward I have plans to use https://rust-lang.github.io/mdBook/ to write MartyPC's documentation. There are a number of output processors from plain text to html to PDF that could then be included with the distribution.

DaveDDS wrote on Yesterday, 01:01:

There's several things about Win10 that I don't particularly like

Microsoft is about to force us all to upgrade to Windows 11, so I feel you. I don't really want to. I was happy with Windows 7 too, for that matter. At this point being a Windows user sort of comes with a forced update treadmill.
I'd have no qualms about running an older version of Windows, except that I'd be nervous about the lack of any security updates for years. Safe browsing habits can keep you somewhat safe, but oy.

DaveDDS wrote on Yesterday, 01:01:

(I personally have developed lots of Win32 applications that run just fine on Win7 or Win10)

This isn't a lack of programming know-how or desire to exclude Windows 7 users. If I was writing in C++ using my old copy of Visual Studio 2015, Windows 7 would just work splendidly with no fuss. I'm just using Rust, which is a new-fangled language, with a certain update inertia and many of my dependencies are bleeding-edge sort of things that add enticing features but make me keep upgrading well past the point the Rust toolchain itself dropped official support for Windows 7.

I still know how to make a Win32 app at the end of the day, HWNDs and LPARAMS and all that fun stuff. I am just far more productive in Rust.

DaveDDS wrote on Yesterday, 01:01:

And... I have to say that with 90 files and consuming 70MB, MartyPC might be more complex than I'd like. For now I'll continue t […]
Show full quote

And... I have to say that with 90 files and consuming 70MB, MartyPC might be
more complex than I'd like. For now I'll continue to use DBDOS...
I'm using an ancient version of DosBox - about 6 files, 2.5MB (and runs
fine in Win7 or Win10)...

Well, let's compare apples to apples. MartyPC is statically compiled, which means it doesn't need a whole bunch of system DLLs or MSVC runtimes that would bloat your comparison quite a bit. I've also got a 32MB VHD file in there that most emulators aren't going to include, and a collection of games and disk images and open-source ROMs. That's all optional stuff. The vast majority of other files are configuration files that allow for definitions of machine configurations, and ROM sets. Having those be external definitions provides power and flexibility. If you want to add a ROM set to 86box, you have to recompile the entire emulator. In MartyPC you can just edit a file.

But I won't try to sell you on MartyPC if you're put off by it. I make no money from it, as much as I would like to see people use my work.

DaveDDS wrote on Yesterday, 01:01:

Btw, No intense offended ... I guess I am just in a "rant about modern software development practices" mood 😀

No offense taken. It's a hard sell to try to convince someone not to just use DosBox. If ease of use is your primary concern than I have little to compete on. What I can offer is a fancy GUI debugger, cycle-accuracy, and the chance to have features you've always wanted in an emulator actually implemented. Trixter wanted a bitmap memory visualizer to see how games drew back-buffers, I made that for him specifically.

I also have IMD support 😉

You can always try out the web version at https://martypc.net - it works fine in Chrome on Windows 7 and you don't have to install anything.

GloriousCow wrote on Yesterday, 01:54:

Unfortunately you need to be logged into Github to download artifacts. If there's some other way I can get the file to you, let me know. I'm guessing that if you don't have a Github account you probably don't use Discord either.

I do(did) use Discord - unfortunately I was out of commission for a couple years, and my injury caused me to lose at least a couple
years worth of memory ... I've not been able to get back into Discord (to be fair I've not really tried - I mainly used it while gaming
with my son which I can't do as well now.. 🙁

Not a big deal - I'll fire up a W10 box and try it and decide if I want to go further.

GloriousCow wrote on Yesterday, 02:16:

Microsoft is about to force us all to upgrade to Windows 11, so I feel you. I don't really want to. I was happy with Windows 7 too, for that matter. At this point being a Windows user sort of comes with a forced update treadmill.
I'd have no qualms about running an older version of Windows, except that I'd be nervous about the lack of any security updates for years. Safe browsing habits can keep you somewhat safe, but oy.

I rarely put my main systems "on the net", and when I do, I'm careful not to do anything I've not done before...

My "solution" to this whole "forced update" thing is - I use Chromebooks to access the net - and not for anything else.
Yes, they auto update - but it doesn't affect the stuff that's important to me. But it's not just that - I actually like desktops
and laptops - I don't need/want them turning into a tablet/phone - and I just get tired of constantly "turning stuff off", and
learning "how it works this week".

I'm just using Rust, which is a new-fangled language, with a certain update inertia and many of my dependencies are bleeding-edge sort of things that add enticing features but make me keep upgrading well past the point the Rust toolchain itself dropped official support for Windows 7.

The kind of thinking that caused me to "lose interest" in Apple....

I still know how to make a Win32 app at the end of the day, HWNDs and LPARAMS and all that fun stuff. I am just far more productive in Rust.
Well, let's compare apples to apples. MartyPC is statically compiled, which means it doesn't need a whole bunch of system DLLs or MSVC runtimes that would bloat your comparison quite a bit. I've also got a 32MB VHD file in there that most emulators aren't going to include, and a collection of games and disk images and open-source ROMs. That's all optional stuff. The vast majority of other files are configuration files that allow for definitions of machine configurations, and ROM sets. Having those be external definitions provides power and flexibility. If you want to add a ROM set to 86box, you have to recompile the entire emulator. In MartyPC you can just edit a file.

Fair-enough - I didn't say DVM <> MartyPC were "equal" - just giving you and idea of how I like "simple" to be.

As you can probably guess, I'm very "old-school" - I got into this whole business using only assembly language and still do a lot of that.
I wrote my own C compiler for a couple reasons: 1) I'd never done a compiler before and wanted to learn how it all worked, and 2) I had
written assembler/debuggers etc. for a ton of little "embedded" processors (which were all different), and I liked the idea of C being
fairly low level without tying you to a specific architecture (obviously important to more than I - I made a good living for many years
selling versions of my development tools for embedded systems - I think by the end I had implemented Compilers,
Assemblers, Debuggers, Disassemblers and many related tools for more than a dozen processor architecture families).

But I won't try to sell you on MartyPC if you're put off by it. I make no money from it, as much as I would like to see people use my work.
... It's a hard sell to try to convince someone not to just use DosBox. If ease of use is your primary concern than I have little to compete on. What I can offer is a fancy GUI debugger, cycle-accuracy, and the chance to have features you've always wanted in an emulator ...

I don't need "ease of use", I just want it to work (without having to get new systems), and give me accurate system emulation, I'm
mainly interested as a "test platform".

I also have IMD support 😉

I noticed that - do you support IMDs read/write? If so, how do you handle "compressed" (all same) sectors? Do you regenerate a new .IMD?
-or do you require the .IMD to be uncompressed: IMDU /E

You can always try out the web version at https://martypc.net - it works fine in Chrome on Windows 7 and you don't have to install anything.

Ok... but my main interest in checking it out is to boot/run a bunch of my own stuff... Can the web version access an image locally or provide another way
to accomplish this?

DaveDDS wrote on Yesterday, 03:31:

I also have IMD support 😉

I noticed that - do you support IMDs read/write? If so, how do you handle "compressed" (all same) sectors? Do you regenerate a new .IMD?
-or do you require the .IMD to be uncompressed: IMDU /E

Just read-only at the moment. I think the PC emulation world is leaning towards bitstream and fluxstream level emulation, but I think it's nice to be able to open older image formats.
However, compression isn't really a huge issue if I wanted to implement IMD writing - I only write to your disk images on request.

DaveDDS wrote on Yesterday, 03:31:

You can always try out the web version at https://martypc.net - it works fine in Chrome on Windows 7 and you don't have to install anything.

Ok... but my main interest in checking it out is to boot/run a bunch of my own stuff... Can the web version access an image locally or provide another way
to accomplish this?

Yes, go to media->floppy drive -> browse for image will open a local file browser. This is all done locally, you're not uploading your files to me or anything.

You can ignore the stated size of the disk drives - anything from 160K to 1.44MB will work.

I plan to expand the capabilities of the web version over time. There's no reason I can't let you upload a whole hard disk image, for example, and there's some virtual filesystem support in modern browsers where the hard disk could be persistent between visits.

What are the maximum visible screen sizes in pixels possible on a real CGA monitor (with a pixel frequency of 14.318 MHz)?
Is it possible to increase the number of visible lines by reducing the frame rate to 50 Hz?

GloriousCow wrote on Yesterday, 02:16:

Well, let's compare apples to apples. MartyPC is statically compiled, which means it doesn't need a whole bunch of system DLLs or MSVC runtimes that would bloat your comparison quite a bit. ...

I'm not certain that's entirely correct - I fired up one of my Win10 systems,
run martypc.exe - and get:

1(X) The code execution cannot proceed because
2    VCRUNTIME140.dll was not fouund. Reinstalling the program
3    may fix this problem.

btw - my little 15k DVM.EXE (also statically linked and really needs no
extras) runs fine, even on a fresh Windows install.

oh - and also btw/fyi - trying to look at README.md brings up a prompt to look in Microsoft store to find an application.

I can mostly read it if I select wordpad, however formatting information for whatever program you used to create it soils the look
a bit - it looks like simple text (perhaps some of the visible garbage is to set font sizes, fonts etc.) - why not just give it
out as a .TXT - every system back to DOS can read that! If you really want to "fancy it up", why not use WordPad --
every recent release of Winblows has that!

re: IMD

GloriousCow wrote on Yesterday, 04:00:

Just read-only at the moment.

I think full .IMD support is probably overkill for a PC emulator ... I designed the format to be able to represent any disk format the Nec765
(original PC FDC) could read - specifically pre-standard and oddball formats used on some classic systems (of which the more off
ones weren't PC compatible at all)

For example, IMD supports single density, oddball sector sizes or other things I've never seen done on a PC. It also does
things like preserving the sector ordering within differing tracks, so it can recreate as close to "exactly" the original disk.

Implementing .IMD seems like a lot of unnecessary work, although at least for reading, you don't have to regenerate
the image - writing however... IMD "compresses" all-same sectors (very common in unwritten portions of formatted
disks) by setting a flag to indicate this is the case, and then supplying only the single byte value. So you would have to
regenerate the image to enlarge formerly compressed sectors that get written...

There are also disk formats where tracks are not numbered sequentially, so IMD records the track number for each track,
it was never designed for tracks to be out of order in the image .vs. the original disk, so there is not additional layer of
"mapping".

I don't think it is at all unreasonable to tell people that if they want to use (especially write) .IMDs in an
emulation, they should use IMDU to convert it to a simple raw binary image containing sequential sectors
first - almost all emulators support that.