Keni
Sweet Seals For You, Always
Misplaced Lens Cap
Aqua Utopia｜海の底で記憶を紡ぐ
⁂
noise dept.
art blog(derogatory)
TVSTRANGERTHINGS
ellievsbear
blake kathryn
Janaina Medeiros
Not today Justin
#extradirty
Origami Around
$LAYYYTER
No title available
oozey mess
PR's Tumblrdome
Three Goblin Art
DEAR READER
seen from United States
seen from United States
seen from United States
seen from United States
seen from Czechia
seen from Türkiye
seen from United States
seen from United States
seen from Malaysia
seen from United States
seen from Japan
seen from United States
seen from Türkiye
seen from Argentina
seen from Canada
seen from United States
seen from Spain
seen from Malaysia
seen from United States
seen from United States
@asspull3x
It's a bit telling, if not maybe damning, that some of the very first posts on this blog were talking about the state of the A3X's software and such, and after all that time not a single word of those posts is outdated. I could repost their contents verbatim and it'd still be entirely true.
The State of the Asspull IIIx, 2026
Emulator: No real need to work on it. All basic features are there, except...
System: ...I had that one idea about page flipping/backbuffers three years back. Never actually did anything about that.
Actual hardware implementation: Wasn't ever gonna happen to begin with.
File manager: Needs more basic functionality, but I appear to have gotten stuck on word wrapping in the text file viewer.
Image editor: Development died out after the main source of inspiration and input went... I'm not sure what to call what happened to them. Incommunicado, let's just say. Tempted to redesign the UI to be less like DeluxePaint to distance from said person, but that just amounts to more senseless busywork without actually adding functionality.
Platform game: Barely anything to show for it. I've always struggled with collision detection, but studying the Commander Keen source code reconstruction is vaguely inspiring.
Basic interpreter: Too, well, basic to be of any use. I really should just port something off the shelf.
Columns: Basic gameplay is in, but no progression or fail state. No settings menu or title screen.
Tetris: Basic gameplay is in, but failing just sits there. No settings menu.
Sokoban: Basic gameplay is in, level pack support from diskette is in. Is supposed to have a level editor.
Anything 3D: I might look into rendering wireframes or better again, now that floating point math is supported.
All in all, it's been... an easy two years now since the last change. Being the only one on the project, I gotta admit it's not easy to keep the drive going. Which is why I started working on other projects.
Which is why I keep doing that, never finishing anything...
I should go to sleep.
How is the A3X different from the Amstrad Mega PC or Sega Teradrive?
Easy. It's really more like an IBM PCJr.
The Mega PC and Teradrive were two pretty much separate systems in a single case (an IBM PC and a Megadrive), with a switch on the front to decide which of the two is on screen.
The PCJr was a single system that happened to have both a diskette drive and a cartridge slot.
The A3X also is a single system with both a diskette drive and a cartridge slot. It just also has a console-like tile graphics mode. And any program code running on the A3X, be it from cartridge or disk, can use it.
Designing your console after the best IBM PC variant: a bold and brilliant move!
Except for the little detail of using a 680x0 processor and the only PC compatibility being the built-in FAT support.
But you know...
How is the A3X different from the Amstrad Mega PC or Sega Teradrive?
Easy. It's really more like an IBM PCJr.
The Mega PC and Teradrive were two pretty much separate systems in a single case (an IBM PC and a Megadrive), with a switch on the front to decide which of the two is on screen.
The PCJr was a single system that happened to have both a diskette drive and a cartridge slot.
The A3X also is a single system with both a diskette drive and a cartridge slot. It just also has a console-like tile graphics mode. And any program code running on the A3X, be it from cartridge or disk, can use it.
I have an idea for a new feature.
Since there's enough VRAM to hold a whole 640×480 8bpp bitmap at once, that means anything smaller than that (say, 320×240?) has room to spare. The bitmap screen also overlaps with the text mode screen and tilemaps -- offset 0 is the top-left character, pixel, and tile.
So what if I added a page bit?
Consider games like the original pre-AGI PCJr version of King's Quest 1. Like on the Apple II, that's a graphical top part with a text-only bottom part:
On the A3X, you might do a mid-screen mode switch but then there would be garbage noise near the top of the graphics, because that's where the text goes.
But if you have pages, you can hit a particular line and switch not only modes but also pages, so the graphics and text don't have to overlap in memory.
This of course wouldn't work for the 640×480 8bpp bitmap mode, because that covers the entire range, but still!
And it doesn't have to be just the bottom 32 pixels (four lines) either. You could switch at any time, including to and from tile map modes.
Just an idea I had last night that Lancette then interrupted to ask how there's no music tracker or graphing calculator on the A3X yet.
Thoughts, anyone?
Lancette: But seriously the Asspull IIIx needs music tracker software and a scientific/programming/graphing calculator. These are good launch package programs Kawa: I find this suggestion unfeasible for me. Lancette: Really? You built the infrastructure it runs on but a calculator is beyond you? Kawa: Especially a scientific/graphing one. But the music tracker is even more unfeasible.
Lancette: You're telling me that you manifested a whole operating system out of thin air, complete with graphics formats, custom cartridge drives, and games, but a calculator is too far. Kawa: YES 😄 Lancette: How. Kawa: Believe it or not, these are completely different areas.
Lancette: You built your own picture viewer. For your own OS graphical management. And yet one of these escapes you. Unbelievable.
Kawa: I wouldn't know where to even begin with one of those.
... I mean, she's not wrong. That would be nice launch software to have. Even though I'd consider the A3X primarily a games system first. I mean, there's a reason it has no GUI.
Kinda funky how "open it, read it" works. First, the automatic listing of things in the room description sets "it" to the mailbox. I enter two commands on one line. The first is parsed as "open mailbox", and the default "open container" handler sets "it" to the leaflet. Then the second command is parsed as "read leaflet", which causes an implicit take.
It makes sense when you think about it, but "open it, read it" on its own... not as much I think.
That whole thing of course has nothing to do with the A3X and is just me rambling about how the underlying framework used in Zork (or rather Mini-Zork) works.
But this is in fact an A3X screenshot. Because the A3X can run Frotz.
I should work on some graphics support a bit, maybe. Technically this is a graphical mode after all, hence the proportional font.
Kinda funky how "open it, read it" works. First, the automatic listing of things in the room description sets "it" to the mailbox. I enter two commands on one line. The first is parsed as "open mailbox", and the default "open container" handler sets "it" to the leaflet. Then the second command is parsed as "read leaflet", which causes an implicit take.
It makes sense when you think about it, but "open it, read it" on its own... not as much I think.
Just found out floating point is fucking broken. I haven't the tools, knowledge, or means to even begin finding out why, let alone fix it...
This should print "3.14" twice. Does it?
For some reason, optimization levels affect the result.
-O0: Neither works. -O1, -O2, -Os, -Og: "This is fine" works, "this breaks" does not. -O3, -Ofast: Both work.
I've been using -Os all this time now, but that really doesn't matter as much as how
this does not make sense to begin with.
I can't reproduce in Linux GCC, but one of the things I figured out from looking at the assembly on the Godbolt Compiler Explorer is that "This is fine" can get optimized into the equivalent of
printf("%d.%d/n", 3, 14);
That's because the compiler does the math at compile time. But the function call can't do that because it can't inline across function boundaries (except at some optimizer levels?) and it actually includes the assembly to do the math.
I literally just found out about that myself, but without Godbolt. Thanks though!
... In my defense, I was freaking out at the time.
Found an interesting filter application. Does stills and videos. So here's a quick thing.
Oh yeah, this is not good.
Musashi (the off-the-shelf 68k core I use), as it was set up now, simply Does Not Support Floats.
And I can't figure out how to get it set up to do support floats, which is a thing it can support, without breaking compilation very badly…
Okay, it compiles. But now the damn thing just straight up quits the emulator when the first FPU instruction hits.
The work doesn't end.
fpgen_rm_reg: unimplemented opmode 27 at 000200B8
It tried and failed to display this message. That's why it quit.
... I got nothing.
What I'm getting from this is that GCC's take on "multiply a float by 100.0f" emits instructions that Musashi doesn't accept. It seems to have FSMUL.S and FMUL, but no FSGLMUL.S?
After all, if I leave the "* 100" out, it runs to completion but gives the wrong answer.
So either GCC is doing something wrong, or Musashi needs updating.
And there's no updates for Musashi.
I hate that this works.
There's probably some implementation detail differences between the other two mul/divs and the two I added here, but it does end up successfully writing "3.14" to the screen. As in the "multiply by 100" works.
("fsglmul and fsgldiv truncate data to single precision before computing results." says one source I found just before adding those two case lines.)
And I hate it.
Near as I can tell from what invertego showed me about GCC, there might be a bug in GCC, and it should emit FSMUL but they got a ?: the wrong way around.
See? But on the flipside, Musashi (especially after the update where I had to jiggle the handle to get floats to compile) ostensibly supports 68040 so it should have FSGLMUL support.
It doesn't make sense and in the end I only needed two extra lines but it seems to work and I fucking hate it.
this is a tangent, especially since you seem to have figured it out (at least to the point where it runs), but are you set on only using Musashi, or would you consider trying out other 68k emulators if it broke again?
I'm open to suggestions and have the free time to try 'em.
Oh yeah, this is not good.
Musashi (the off-the-shelf 68k core I use), as it was set up now, simply Does Not Support Floats.
And I can't figure out how to get it set up to do support floats, which is a thing it can support, without breaking compilation very badly…
Okay, it compiles. But now the damn thing just straight up quits the emulator when the first FPU instruction hits.
The work doesn't end.
fpgen_rm_reg: unimplemented opmode 27 at 000200B8
It tried and failed to display this message. That's why it quit.
... I got nothing.
What I'm getting from this is that GCC's take on "multiply a float by 100.0f" emits instructions that Musashi doesn't accept. It seems to have FSMUL.S and FMUL, but no FSGLMUL.S?
After all, if I leave the "* 100" out, it runs to completion but gives the wrong answer.
So either GCC is doing something wrong, or Musashi needs updating.
And there's no updates for Musashi.
I hate that this works.
There's probably some implementation detail differences between the other two mul/divs and the two I added here, but it does end up successfully writing "3.14" to the screen. As in the "multiply by 100" works.
("fsglmul and fsgldiv truncate data to single precision before computing results." says one source I found just before adding those two case lines.)
And I hate it.
Near as I can tell from what invertego showed me about GCC, there might be a bug in GCC, and it should emit FSMUL but they got a ?: the wrong way around.
See? But on the flipside, Musashi (especially after the update where I had to jiggle the handle to get floats to compile) ostensibly supports 68040 so it should have FSGLMUL support.
It doesn't make sense and in the end I only needed two extra lines but it seems to work and I fucking hate it.
Oh yeah, this is not good.
Musashi (the off-the-shelf 68k core I use), as it was set up now, simply Does Not Support Floats.
And I can't figure out how to get it set up to do support floats, which is a thing it can support, without breaking compilation very badly…
Okay, it compiles. But now the damn thing just straight up quits the emulator when the first FPU instruction hits.
The work doesn't end.
fpgen_rm_reg: unimplemented opmode 27 at 000200B8
It tried and failed to display this message. That's why it quit.
... I got nothing.
What I'm getting from this is that GCC's take on "multiply a float by 100.0f" emits instructions that Musashi doesn't accept. It seems to have FSMUL.S and FMUL, but no FSGLMUL.S?
After all, if I leave the "* 100" out, it runs to completion but gives the wrong answer.
So either GCC is doing something wrong, or Musashi needs updating.
And there's no updates for Musashi.
Oh yeah, this is not good.
Musashi (the off-the-shelf 68k core I use), as it was set up now, simply Does Not Support Floats.
And I can't figure out how to get it set up to do support floats, which is a thing it can support, without breaking compilation very badly…
Okay, it compiles. But now the damn thing just straight up quits the emulator when the first FPU instruction hits.
The work doesn't end.
fpgen_rm_reg: unimplemented opmode 27 at 000200B8
It tried and failed to display this message. That's why it quit.
... I got nothing.
