Disk explorer is great tool, but I miss the proper viewing of BASIC files. Can you add it to the list of new features for the next update?
Yeah, I'll get to that at some point.
Since 2.70 is in the early stages already, what do you think about adding 3 things to the user interface?
1- The ability to "load" various iterations of the altirra.ini file from within the emulator?
Been thinking about this, but it's a pretty big change as it involves a major reworking of the way settings are saved. Right now they just go into a big ball and come out as a big ball, and the emulator has no concept of profiles or classes of settings. The device refactor helped a little bit as at least now there's a consistent path for device settings, but that's only a small part.
2- The next thing (unless I'm missing it somehow) would be to include a list of the command-line options in the .chm file or from a pull-down within the Help menu.
Yeah, yeah... there's never enough time to write docs. Actually, it's weird that we have so many people here who apparently actually read help files. I'd thought those were an endangered species by now.
3- I want to see the firmware selection box cleaned up a little.
I agree, but not with your color scheme.
At one point I did have an implementation that used Vista Explorer like grouping instead with headers in a slightly bigger font, and it did generally look better, but just couldn't get the horizontal positioning right. Stupid control kept wanting to have the items farther left than the headers (WTF) and reserving space for non-existent icons.
One problem with trying to redesign this dialog is that it essentially has two duties -- to show you what ROM images are available and also to show what classes of images can be installed. That means, for instance, switching to a flat list doesn't work well.
4- While I'm typing this stuff up.. Is it possible to become more efficient on the rendering of the scanlines? On a couple lower-end systems (think Pentium-M 1.7GHz) I see as much as a 50% increase in CPU time. Ohh sure it isn't an i7. So that's just a thought.
Try 2.70-test1 if you haven't already -- it contains an SSE2 optimization for the scanlines. 50% higher on a P-M sounds like more like video overhead, though. Turning on scanlines with artifacting still off requires switching the display format from 8-bit to 32-bit, which requires more CPU. Getting it down further will probably require rendering the scanlines on the GPU, for which I don't have infrastructure yet (and will be slightly annoying, due to multiple rendering APIs).
I have checked the error disk explore right mouse pressed when no file is selected this is happen from altirra 2.60 test 32 to the latest version you can check this from the link: http://www.virtualdu...2.60-test31.zip
Thanks...simple issue, will be fixed in next test build.
I am always wondering how it is done. Surely Phaeron doesn't own all of these devices?
How is it done?
I actually do have a fair number of these devices, but not all of them. The PBI devices, for instance, were done without.
If I can get a functional description and software that uses the hardware, that's usually enough. For commercial hardware, that usually requires a register-level description, and sometimes schematic or firmware dump and cross-referencing with datasheets. The 1030 was one of the harder cases as I only had the software driver at first, which meant reversing that to get a functional spec and then reimplementing the functional spec. Simpler stuff like the MidiMate just requires knowing which pins which go to which chips. Once I have that info, I can "wire" up the chips in Altirra, which usually goes pretty quickly if I already have the chips emulated. A lot of the remaining time is either figuring out why the software malfunctions or optimizing the emulation to acceptable speeds.
Homebrew hardware is usually the same way, although I actually prefer getting the VHDL/Verilog source if possible. Hardware engineers have a habit of leaving stuff out or getting stuff wrong, and it slows things down when they tell me a bit goes one way and it actually goes the opposite way.
Past that point, having the actual hardware is usually only needed for going past functional emulation to highly accurate emulation. I just recently acquired a real 1030 modem, and one of the changes in 2.70 test-1 is that the emulator bootstrap now approximately matches the sound variations you hear when booting off a real 1030. For some reason, the firmware sends different parts of the driver and ModemLink software at different speeds, which you can hear. It's one of the weird quirks of the hardware that would be lost just working off a functional spec.
BRK is a two-byte opcode. Change it to what and for why?
Well, it sort of is and isn't. BRK takes two bytes because of the way the 6502 updates the PC, but it doesn't use the second byte. You'd have to access the second byte via a special IRQ/BRK handler, which no one does because it screws up your interrupts and takes a load of cycles. I changed this at some point to match the typical behavior, but it does screw up reverse disassembly, so I'm probably going to revert it.
how i can save ROM from altirra emulator?
somewhere here i found test rom from altirra
You'd have to use a ROM saving tool for now. However, no new changes besides updating the version number -- OS is otherwise unchanged, BASIC is still 1.38. I'm planning on setting up a separate ROM pack in the future.