SoftCat wrote on 2025-05-19, 19:59:

Can someone explain to me how the line "See ya!" is stretched horizontally in AREA 5150? How do the CRTC register values ​​change?

The stretch isn't done via CRTC shenanigans, it's an animation. It's the same basic technique used throughout the demo, drawing graphics with the tops of character glyphs.

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

I've been looking for a "simple PC"" emulation.
I've tried a few, but all I've gotten to work so far is "VMware Player" and
my own "DBDOS" (which boots "real DOS" under DosBox).
- VMWARE is way to big and doesn't have good screen emulation (I end up
working in a tiny window)
- DBDOS works well, and it's what I normally use for "real DOS" on my desktop,
but it doesn't implement less than a 386
(I'd like to be able to test stuff on an XT or AT)

I've tried "86BOX", but have never gotten as far as booting - it wants a BIOS
ROM, I found a generic one, but it's not clear if it will actually work.

MartyPC looks promising and it's nice to see that it's still being worked on,
but so far I've not had much luck.

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)

If I run: martypc.exe
"(X) The application was unable to start correctly (0x0000005). Click OK to
close this application."

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.

If I try to access any of the Help in martypclauncher, I get:
"(X) https//github.com/dbalsom/martypc/wiki/{helpfilename}"
Application not found"

I must be missing something fairly basic ... ??

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

The stretch isn't done via CRTC shenanigans, it's an animation. It's the same basic technique used throughout the demo, drawing graphics with the tops of character glyphs.

The attachment text_effect.PNG is no longer available

I see, thank you for the clarification.

GloriousCow wrote on 2025-05-19, 14:24:

Well, the V20 doesn't have a unique set of 8080 registers - they are mapped to the existing 8086 register set.

I realize that, but for someone knowing 8080/Z80 assembly this will look really odd.

The CPU status window isn't going to switch to 8080 register names in emulation mode. So it's sort of a matter of deciding what is more confusing to look at.

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

JAL

Just took a look at the NEC V20 (upd70108/70116) documentation to take a look at the 8080 mode (haven't implemented that myself either)... holy.... Pretty much all x86 instructions have completely weird names.
Also, the 8080 instructions aren't documented at all? Mainly interrupts a bit and register mapping (somehow BP instead of SP in emulation mode stack addressing, accumulator is still AL, flags is the same(lower byte only), others are mapped directly to B/C/D registers (HL,BC,DE respectively, H being high and L being low) and SI=IX, DI=IY apparently).
The way the stack if modified is odd though. Why BP instead of SP?
Also does the 8080 have interrupts? Are those simply redirected to x86 interrupts?
Is SS still used with BP for stack on 8080?
8080 instructions aren't documented except for the emulator instructions (CALLN/RETEM)?

From what I can gather:
RETEM is like IRET, but setting bit 15 and disabling it's setting by IRET and POPF?
CALLN is like INT, but setting SP to 6 below CS('PS' in the documentation)? Or is that supposed to be 6 below SP?
And BRKEM is like INT, but clearing bit 15 of FLAGS and enables IRET/POPF to clear it?

reenigne wrote on 2025-05-19, 15:22:

GloriousCow wrote on 2025-05-19, 14:24:

Well, the V20 doesn't have a unique set of 8080 registers - they are mapped to the existing 8086 register set.

That's interesting that BX/CX/DX are mapped to HL/BC/DE respectively because those are the same names that Intel's 8086 patent gives to those registers in their microcode snippets. I didn't realise that mapping was an (apparently canonical) 8086/8080 mapping.

I suspect it's more because HL has a "special capability" that's shared with BX. ie: the ability to access memory indirectly through it.
You'll find that a lot of 8086 "features" are directly based on the 8080 architecture.
Intel had the goal of making the 8086 as upward compatible with the 8080 as possible, that's why some of their early
8086 docs/ patents reference 8080 "names" in places.

8080 allows [BX], 8080 uses the "register" 'M' to refer to memory pointed to by HL. IE:
-8080- MOV A,M
directly translates to:
-8086- MOV AL,[BX]
DI and SI also support this on the 8086, but they can't be directly accessed as High/Low bytes
BX has BH=H and BL=L -- again 1:1 instruction translation

In a V20 emulation, I would prefer/suggest that when the V20 is in "8080 mode", the register names
also show the 8080 equivalents.
eg: if you normall show: BX: xxxx
in 8080 modem you might show BX[HL] xxxx

That way the users doesn't have to remember the V20<>8080 mapping, but it doesn't cause "noise" in
normal 8086 debugging. (You might have key to switch mode displays interactively for those cases where
you are debugging "special" code that swaps back and forth between modes - but I would expect programmers
developing such code to know the mapping quite well)

superfury wrote on 2025-05-20, 11:28:

...Also, the 8080 instructions aren't documented at all? ...

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.
[You can actually experience running my Altair, booting up a 1970s-OS (North-Star DOS), using
the ADM3A console terminal - all from my Altair simulator available on "Daves Old Computers"]

Back to the message above, I've included scans of a few 70s Intel manuals on the site, including
"8080A Assembly language Programming Manual" which gives lots of detail on what the instructions
are and what they do.

Go to: Daves Old Computers -> Altair 8800 -> Altair documentation"
- look in the "Reference documents" section

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

superfury wrote on 2025-05-20, 11:28:

...Also, the 8080 instructions aren't documented at all? ...

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.
[You can actually experience running my Altair, booting up a 1970s-OS (North-Star DOS), using
the ADM3A console terminal - all from my Altair simulator available on "Daves Old Computers"]

Back to the message above, I've included scans of a few 70s Intel manuals on the site, including
"8080A Assembly language Programming Manual" which gives lots of detail on what the instructions
are and what they do.

Go to: Daves Old Computers -> Altair 8800 -> Altair documentation"
- look in the "Reference documents" section

Ok, took a quick look at http://dunfield.classiccmp.org/r/8080.txt
It looks that pretty much most if not all those instructions can be routed to the usual modr/m based system, or flat out mapped directly to x86 instructions (like CLI/STI)?
They just need manual modr/m settings for all opcodes and other immediate (byte/word) handlings, as those differ from x86 opcodes?
Also, what about it's IN/OUT instructions? Are they simply remapped to OUT imm8,AL and in AL,imm8?
Or are those faulting #UD for the emulator to handle?
Aren't the x86 0F prefixed instructions incompatible with x86 of Pentium Pro and higher (conflicting instructions and parameters)? Is it just using normal modr/m there or does it have some weird encoding?

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?

JAL

superfury wrote on 2025-05-20, 11:28:

Just took a look at the NEC V20 (upd70108/70116) documentation to take a look at the 8080 mode (haven't implemented that myself either)... holy.... Pretty much all x86 instructions have completely weird names.

The manual provides a translation table to Intel names. I suppose that was some lawyer's decision to rename everything.

superfury wrote on 2025-05-20, 11:28:

The way the stack if modified is odd though. Why BP instead of SP?

This preserves the native stack pointer, which is important. If the emulated program was allowed to mess up the stack pointer you couldn't exit emulation mode.

superfury wrote on 2025-05-20, 11:28:

Also does the 8080 have interrupts? Are those simply redirected to x86 interrupts?

Yes, hardware interrupts in emulation mode will be executed in native mode, and then IRET will return to emulation mode by popping the flags. If for some reason your ISR does not pop the flags you're gonna have a bad time.

superfury wrote on 2025-05-20, 11:28:

Is SS still used with BP for stack on 8080?

No - 8080 code cannot touch the native stack, unless you happened to map CS or DS to overlap it. So the 8080 stack is in DS.

superfury wrote on 2025-05-20, 11:28:

8080 instructions aren't documented except for the emulator instructions (CALLN/RETEM)?

I suppose they expected you to read the i8080 manual.

superfury wrote on 2025-05-20, 11:28:

From what I can gather:
RETEM is like IRET, but setting bit 15 and disabling it's setting by IRET and POPF?

RETEM pops the flags that BRKEM pushed. BRKEM pushed the flags with the M bit set for native mode before clearing the M bit. So RETEM pops the flags with the M bit set and re-enters native mode.

superfury wrote on 2025-05-20, 11:28:

CALLN is like INT, but setting SP to 6 below CS('PS' in the documentation)? Or is that supposed to be 6 below SP?

CALLN is almost exactly like a software interrupt that sets the M flag to enter native mode. The flags it pushes to the stack have the M bit cleared so that IRET will pop them and return to emulation mode.

superfury wrote on 2025-05-20, 11:28:

And BRKEM is like INT, but clearing bit 15 of FLAGS and enables IRET/POPF to clear it?

BRKEM is exactly like a software interrupt that just clears the M flag to enter emulation mode. The flags it pushes to the stack have the M bit set so that when RETEM pops the flags it will re-enter native mode.

superfury wrote on 2025-05-20, 15:37:

It looks that pretty much most if not all those instructions can be routed to the usual modr/m based system, or flat out mapped directly to x86 instructions (like CLI/STI)?

8080 decoding is extremely simple. It is an octal organization. You can basically decode the operation and parameters directly from the octal fields of the opcode.

superfury wrote on 2025-05-20, 15:37:

Also, what about it's IN/OUT instructions? Are they simply remapped to OUT imm8,AL and in AL,imm8?

As far as I can tell they work as expected but you're limited to IO addresses 0-255.

superfury wrote on 2025-05-20, 15:37:

Or are those faulting #UD for the emulator to handle?

The V20 has no #UD to fault on.

superfury wrote on 2025-05-20, 15:37:

Aren't the x86 0F prefixed instructions incompatible with x86 of 286+?

NEC was careful to avoid 286 extended opcodes, but Intel didn't appreciate them playing in their sandbox so 386 tramples on them.

superfury wrote on 2025-05-20, 15:37:

Ok, took a quick look at http://dunfield.classiccmp.org/r/8080.txt

Thats a summary ... it's been so long, I don't recall where I got it, quite likely I wrote it "back in the day"
when designing my first 8080 assembler (ran on my homebuilt 8080 system), no disks or text editor...

You might want to look at the one above it on my page, that's a scan[.PDF] of the actual Intel 8080
programming manual.

... My "editor assembler" (which I "hand assembled" and entered a byte at a time via my 8080 monitor
(fortunately the UNB mainframe/EElab had an 8080 assembler, and an EPROM progrmmer)
let me enter/edit ASM code and assemble it "in memory" also had commands to save/load it's text
file as well as memory blocks (so I could save the final program) to a "Tape drive"

--The tape system was "interesting" at the time I was attending UNB "University of New Brunswick", and
they had a "language lab" which was decommissioning a bunch of solenoid (remote) controlled 5" reel-to-reel
tape drives - naturally I brought a couple home, and designed my own digital recording circuitry (they were
originally audio decks) - at first I just controller them via the front panel buttons, but eventually
I expanded my 8080 machine language monitor/debugger to include "tape" operationsm and made
a software interface so any running programs could save/load to tape.
... I guess in a way, it was the first O.S. I wrote! (You can see the setup in one of my system photos on
Daves Old Computers)

It looks that pretty much most if not all those instructions can be routed to the usual modr/m based system, or flat out mapped […]
Show full quote

It looks that pretty much most if not all those instructions can be routed to the usual modr/m based system, or flat out mapped directly to x86 instructions (like CLI/STI)?
They just need manual modr/m settings for all opcodes and other immediate (byte/word) handlings, as those differ from x86 opcodes?
Also, what about it's IN/OUT instructions? Are they simply remapped to OUT imm8,AL and in AL,imm8?
Or are those faulting #UD for the emulator to handle?
Aren't the x86 0F prefixed instructions incompatible with x86 of Pentium Pro and higher (conflicting instructions and parameters)? Is it just using normal modr/m there or does it have some weird encoding?

In the last year I've released source code for pretty "Everything I've ever written" for myself (ie: not
on a contract where someone else has the rights to the code) - You can look at my Altair simulator there

I don't think any opcodes are "the same" (at least not intentionally) between 8080 and 8086,
the idea was for the 86 to be as upward source code compatible as possible (there are programs - I've
written at least 1 - which translate 8080 .ASM source code to 8086 .ASM source - making it MUCH
less work to port from one to the other)

- I basically use a indexed[by opcode] JMP table, much of which just executes one or two
8086 instructions, but some more complex ones do more.

8080 IN and OUT is just to 256 I/O ports, which is basically a separate set of selects (ie: another address space)
The 8080 IN & OUT are two byte instructions 1st being the opcode, and 2nd
being the I/O port address - the 8080 has no way to indirectly access an I/O port
(my monitor builds a little subroutine in RAM to allow the port to be specified)

[In my Altair emulator, IN/OUT cause the "CPU interpreter" call code within the
emulator in response to IN/OUT which controls the virtual instances of the real devices
I had on my Altair]

Please tell me how "SAME-LINE" and "text+gfx?" are written here with characters 8 dots high, and in the middle the picture is drawn with the upper parts of the characters 1 or 2 dots high.

SoftCat wrote on 2025-05-20, 18:42:

Please tell me how "SAME-LINE" and "text+gfx?" are written here with characters 8 dots high, and in the middle the picture is drawn with the upper parts of the characters 1 or 2 dots high.

So this effect is really quite clever. Nothing you see is a full text glyph, the "text" that you see is drawn with the top rows of other character glyphs, just like the "graphics". Normally the "ANSI from Hell" technique is limited to using the top *two* rows of glyphs as a full screen of that exhausts the 16K of CGA graphics memory, and this can give the effect away to the astute eye.

The key here is that there are several regions of the screen where there are blank areas. These areas don't consume any space in VRAM to draw as we are controlling the CRTC's frame generation and start address. So we can use just the top row of each glyph without running out of memory, as long as we reserve about half of the screen as blank space. That makes it possible to reconstruct the CGA's character glyphs in entirety using just the top row of other character glyphs. At least for the glyphs you see used here - perhaps VileR can chime in, if he was able to reproduce the whole character set this way or not.

Notice in the VRAM visualizer there is no actual gap between the rows of text, or between the text and the artwork.

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

So this effect is really quite clever. Nothing you see is a full text glyph, the "text" that you see is drawn with the top rows of other character glyphs, just like the "graphics". Normally the "ANSI from Hell" technique is limited to using the top *two* rows of glyphs as a full screen of that exhausts the 16K of CGA graphics memory, and this can give the effect away to the astute eye.

The key here is that there are several regions of the screen where there are blank areas. These areas don't consume any space in VRAM to draw as we are controlling the CRTC's frame generation and start address. So we can use just the top row of each glyph without running out of memory, as long as we reserve about half of the screen as blank space. That makes it possible to reconstruct the CGA's character glyphs in entirety using the tops of character glyphs. At least for the glyphs you see used here.

I understand, thank you very much.

SoftCat wrote on 2025-05-20, 19:13:

I understand, thank you very much.

If you want to explore this for yourself, open the Data Visualizer under Debug -> Memory, w to 640, h to 800, then set the BPP (the upper-right dropdown) to Text. That will give you a view that shows the entirety of VRAM as character glyphs. It will show you exactly how most of the effects in Area 5150 are done.

You can tweak R9 too to see it rendered with a configurable number of scanlines per character row.

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

If you want to explore this for yourself, open the Data Visualizer under Debug -> Memory, w to 640, h to 800, then set the BPP (the upper-right dropdown) to Text. That will give you a view that shows the entirety of VRAM as character glyphs. It will show you exactly how most of the effects in Area 5150 are done.

You can tweak R9 too to see it rendered with a configurable number of scanlines per character row.

Got it, thank you!

As the first line of any symbol, you can use this symbol itself. But here, for some reason, the first lines are taken from other symbols.

It is easy to write a program and check by simple enumeration whether it will be possible to reproduce all symbols or not.

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

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.

SoftCat wrote on 2025-05-20, 19:31:

As the first line of any symbol, you can use this symbol itself. But here, for some reason, the first lines are taken from other symbols.

It is easy to write a program and check by simple enumeration whether it will be possible to reproduce all symbols or not.

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. 😉

SoftCat wrote on 2025-05-20, 19:31:

As the first line of any symbol, you can use this symbol itself. But here, for some reason, the first lines are taken from other symbols.

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 😁