New (Updated) Assembler/Text Editor

[flashjazzcat]

I was always a fan of the CIO (or SIO) idea. I somehow envisaged it being primarily applications which would want to judiciously speed up the emulator, get host environment data, etc, etc. Demos and games are hardly going to benefit from being able to switch on "turbo" mode, I wouldn't have thought. The main "host" communication channel in emulators at the moment is "H:" (hard disk), and that's dependent on the OS and CIO. Why not just extend that idea: a few XIO commands on the "H:" device and we're done.

[atarimac]

One of the advantages the CIO idea has is that there is a way to pass parameters, and to get information back from the emulator. We are going to get one shot at this idea, and it needs to be a generalized interface. If we ca get the general idea flushed out, I can take it to the other emulator authors (I do Atari800MacX, and contribute to Atari800, so I would contact the Altirra and Atari++ authors) and try to get it standardize. It should be extensible as well with new commands in the future, as I'm sure we can't anticipate everything.

 

I totally understand Steve's comments if the OS is not there. The issue is getting command codes and parameters/return values in and out, being limited to only the A, X, and Y registers. Perhaps we could use the IOCB structure in zero page that CIO would be using normally, since we shouldn't expect to be doing a CIO operation at the same time if we are doing the special opcode sequence. One of the other reasons for the parameter exchange is a return value, since I want it to do more than not do anything on real hardware, I want it to be detectable that it did nothing (in other words, the emulator would change a register that wouldn't get changed on real hardware), so the program could detect that the operation failed on the real hardware, and know that it is running on real hardware.

 

So for example, different commands would be present for getting from the Emulator:

Emulator Type you are running on.

Emulator version number you are running on.

Host Type you are running on.

Separate commands for various settings of the emulator

 

And then to send to the emulator:

Seperate commands for various settings of the emulator.

 

Comments?

 

Mark

[atarimac]

One other comment. Steve mentioned toggling the disk patch, and I don't disagree that might be one of the things that should be changeable. The thing to be aware of is that doing this on most emulators causes a reboot of the emulated atari, so the Atari program that did it would have to know that would happen, and perhaps be rerun through some sort of autorun.

[phaeron]

The main issue I have with the idea of emulator control is that it starts to stray away from emulating real hardware -- you're starting to emulate something that doesn't actually exist. I find it especially odd for something like an assembler/editor, since personally I'd never edit/assemble in the emulator when I could do it on the host instead. Heck, at that point you might as well think about adding an MMU, the ability to swap out I/O space, disk drive DMA, etc. and then it's not related to an Atari anymore. I've already seen numerous cases where people wrote programs that only worked on an emulator and failed on the real hardware, which worries me a bit. I'd like to think that everything that's emulated in some way relates to something that had a soldering iron applied to it.

 

That having been said....

 

The idea of using a NOP instruction pattern is good, especially if it's limited to the illegal NOPs, because then it doesn't involve slowing down any common paths in the CPU emulation. The main downside to doing this is that there isn't opcode space available when emulating a 65C816. An alternative would be a PBI device in I/O space, or a more complex unlocking pattern. I can't speak for any other emulator authors, but I'd like to avoid any pattern detection of valid insns or RAM space; those would be expensive to implement.

 

Regardless of the functionality or mechanism, I'd likely prefer for such functionality to default off, for a couple of reasons. First, it would be bad if the default configuration allowed a program to break out of the sandbox in any way, as amusing as it might be for someone to be 0wned by an Atari program. Second, I have a goal to try to make Altirra as transparent of an emulator as possible -- in theory, it should be possible to emulate well enough that a program can't distinguish the emulator from the real hardware. I'd like the defaults to reflect that.

[snicklin]

The main issue I have with the idea of emulator control is that it starts to stray away from emulating real hardware -- you're starting to emulate something that doesn't actually exist. I find it especially odd for something like an assembler/editor, since personally I'd never edit/assemble in the emulator when I could do it on the host instead. Heck, at that point you might as well think about adding an MMU, the ability to swap out I/O space, disk drive DMA, etc. and then it's not related to an Atari anymore. I've already seen numerous cases where people wrote programs that only worked on an emulator and failed on the real hardware, which worries me a bit. I'd like to think that everything that's emulated in some way relates to something that had a soldering iron applied to it.

 

That having been said....

 

The idea of using a NOP instruction pattern is good, especially if it's limited to the illegal NOPs, because then it doesn't involve slowing down any common paths in the CPU emulation. The main downside to doing this is that there isn't opcode space available when emulating a 65C816. An alternative would be a PBI device in I/O space, or a more complex unlocking pattern. I can't speak for any other emulator authors, but I'd like to avoid any pattern detection of valid insns or RAM space; those would be expensive to implement.

 

Regardless of the functionality or mechanism, I'd likely prefer for such functionality to default off, for a couple of reasons. First, it would be bad if the default configuration allowed a program to break out of the sandbox in any way, as amusing as it might be for someone to be 0wned by an Atari program. Second, I have a goal to try to make Altirra as transparent of an emulator as possible -- in theory, it should be possible to emulate well enough that a program can't distinguish the emulator from the real hardware. I'd like the defaults to reflect that.

 

I personally would not like to see anything which is specific only to emulation, such as some supercomputing routine which could never be done on an Atari. On this matter, I completely agree with you Phaeron. If we did have such a routine, why don't we just run it on the PC? But if we could have an Atari based routine which could maybe do it quicker if on a PC, I don't feel that this breaks the ethos of Atari development. In my opinion.... with a choice of between 30 seconds for a compilation and 3 seconds, I'll take the 3. Nobody gets nostalgia from long IO times.

 

As for the 65C816, this is above my head, so I cannot comment, I'll take your word on this.

 

Functionality defaulting to off - yes, I agree. Unless you intentionally switch it on. As for the chance of a clash between a program operating and accidentally switching on a routine, if we make it several bytes long, we could make it as likely as an MD5 hash clash - i.e. not likely. If it's expensive cpu-wise to implement though, ok, lets use a different method to implement it.