Release BeebEm alpha, Acorn BBC Micro emulator


Yeah, that's the other way to work around the bug, but it's something you can only do after the first run, so the first run will always fail at loading discs. I propose ptit_Seb just makes that directory in the appdata if it's not already there - I believe that's what most emus on this system do.

Edit: And to test this I've always deleted my appdata before running it. Otherwise as you say it'll just remember the actual folder I configured.
 
I fixed that last 0.5 bug. Do you think I should upload that pnd to the repo (so there will be 2 version of that emu on the repo)?
 
Yep, @sswam is. He can put me maintenair of the package, or I can send him the updated sources so he can repackage, or if he doesn't come here anymore, I can just put a second copy.
 
I'd personally prefer to get Sswam's blessing before taking this project from him, but if you want to just push it to the repo and be done with it while you work on other stuff, I can understand that too.

Edit: Presumably if you push this as a second version, people wouldn't get an automatic upgrade with PNDManager, and they wouldn't necessarily know about this release unless they've followed this thread. And they'd end up with two beebems in their menus unless they removed the old one.
 
FWIW, just in testing the ssd format, I just made a file that was bigger than the system RAM (but smaller than the disc it came from), and tried to load it into BASIC which caused the emulator to crash. Perhaps that was because it trashed the interrupt vectors in zero page (with 0 bytes) as it wrapped round, which would sooner or later cause a real BBC Micro to be stuck in a loop of BRK instructions, causing non-maskable interrupts and effectively terminating the OS. It certainly got past the screen ram before it crashed.

No idea what would happen on a real BBC Micro. As I say I suspect it'd probably freeze, because even if a timer interrupt didn't kill it it'd go on to try to write over a ROM and that would cause some sort of exception - but the handler vectors for that have already been trashed. But obviously it wouldn't crash back to the launcher on real hardware, so it is doing something different. I don't expect you to do anything about that though, since it's not a situation I can imagine being replicated in any real software.

Actually, looking into it further a BRK effectively jumps forward two bytes, and the first vectors trashed are used by BASIC so it'd probably nuke BASIC and start trolling through zero page, but what exactly happens depends on how far it got before it terminated BASIC. There'd probably still be some vectors with valid JMP instructions in them which it would crash into then probably into genuine OS code, assuming it was aligned to them properly. But exactly what that would do is rather undefined.

Edit: Thinking further, it'll have blanked the hardware mapped sector above 0x8000 too, and that can do some funky things. I know at least I managed to kill video output using an undocumented *FX 153 command - but I don't really know what I'm doing there so I probably gave it bad values. I've no idea what you could manage by squirting zero values at all of those chips - crashing is maybe a reasonable approximation after all.

[doublepost=1461703433,1461690057][/doublepost]Also, I've noticed it seems to always think the write disable tab is covered, which makes me wonder why it has an option to create a new disc. All it does is make an empty disc file with no title and boot options, and no way to fill it or change any settings. Is that partially implemented functionality, and one of the reasons why it's still at v0.6?

Some of the later Superior Software supported saving games to disc (as did Acornsoft's Elite, I think) so if anyone can test those and see if saving works, it might be worth knowing.
 
Last edited:
Not sure if this is a bug fix request or feature request. I can fix some bug, but feature request, on an emu for machine I don't know, I don't think I can help.

Anyway, the PND is on the repo now.
 
The emulator crash is for now just a note in case it's reproduced in the future.

The discs not being writable is in some ways a feature request, but not being able to play classics like Elite properly might be considered a bug! But the release as is lets me play hundreds of simpler games perfectly well, so I wouldn't say it was without merit ;)

FWIW, I'm currently knocking together a python library that lets you pack and unpack ssd files, which perhaps might be of some use in understanding the format. I'll post here once I've got anything worth publishing. Maybe I'll have a dig in the beebem source once I'm happy with this.
 
Okay, so here's my WIP that can unpack .ssd disc files and catalogue them for you: https://github.com/williain/dfstran

Next up on the feature front is the ability to generate .ssd files from unpacked inputs, so you can use it to modify your disc files, but you'll have to wait for that.

A question for the crowd: does anyone use .dsd files? They're meant to be images of double sided discs, but as far as I know no games were released on double sided discs (IIRC some were written to both sides, but meant to be used as a 'flippy' floppy disc with 40 track on one side, and, flip it over and you get 80 track). Currently the code only supports ssd files, and would just treat a .dsd file as a disc image with 100/200k of unused data at the end. Anyone care?
 
You must log in or register to reply here.
Back
Top