danwinslow

PM me anyone who's interested.

Haha told ya pix

I will go ahead and say I can finance, at least most if not all of it. I have no time for any of the other legwork, so you guys will have to do that.

One for me.

We could license it and have 200 produced professionally. It would take agreement from him and a coordinated group of folks here with a leader and some money.

I bought the one before this one and I'm definitely using it. Just because it gets expensive doesn't necessarily mean shill buyers and profiteering.

Nice I love those things. I made a decision to downscale and just focus on the 8 bits. Still have a couple falcs to go, but I am keeping my original ST I bought in the long ago.

Hmm, if you want to sell the 1200 let me know.

Well, sure, but I think the OP was actually looking for something a little more than just a remote connection to a Linux box. With the XEP, you'd still be making the text available to programs...as a remote connection the text only lives on the PI. He wants to use it as a 'virtual screen', so it would have to be mapped to do what the atari expects in all cases, and there isn't a TTY terminal mapping that matches that. So you'd have to have something in between to interpret the atari behaviors. You'd also need something on the atari side buffering characters, which S: or E: will do, but you need ti intercept and suppress the regular atari screen output too, which a normal serial connection will not do. So, I would write a PI side client that would act like a custom SIO device, kind of like the SIO2PC stuff does but a lot simpler. It would bring up a screen designed to look like an atari 80 col display (blue background FTW), and it would listen for keystrokes and screen write outputs coming along the SIO connection. Then, on the Atari side, I would steal the vectors from S: and E: and redirect them through my own handler to send the info to the PI device, and then pass the data back to the S: and E: device to process 'normally'. I'd have the screen display turned off on the atari most likely.

It wouldn't blank it, but it might freeze/slow it down, but it does that already, so you wouldn't notice in all probability.

Yes, its really all about where the PI thinks it's getting key strokes from. I don't know about straight into VI or Pico, for two reasons: 1. There will need to be some kind of SIO response from the PI for it to participate as a SIO device. Of course, you could go straight serial through an R: driver, but then you'd need the linux serial TTY set up, which isn't hard to do. 2. Vi or Pico will be expecting a certain key mapping and set of commands. Somebody in between would need to map the atari keys and the atari program output ( such as print a character at position x,y ) to commands that would effect the same result on the screen.

Oh absolutely, I was just saying if you aren't sure whats going on, it's best to follow the 'strict rules'.

That's the spirit!

I'm sure there are other native ATARI ways, but basically you download and setup the Altirra emulator on a PC, and use that. You'll have to get your code over there, and that's the hard part, but it can mount any ATR or pc directory as an 'atari disk'. So you'd need some way to turn your atari disk that you're using into an ATR, or maybe you are already using some kind of device other than an actual atari disk drive, and maybe already have it as an ATR. But anyway, then in Altirra you turn the debugger on, hit F8 (break) and use console commands like BP $1234 to set a breakpoint. Then when your breakpoint hits it will stop and you will see a nice disassembled panel full of your code with all registers shown. You can single step and stuff like that. It makes assembler programming almost easy. Almost.

It's not hard, but it's probably a bad idea. The reason you are getting lost in your return stack is your own fault, and you should fix your code rather than arbitrarily deciding to clear the stack. If you 'clear' the stack, you will be destroying return information, and since you don't know where to stop, you will probably trash the whole machine at some point. Every JSR must be followed by an accompanying RTS, including the JSR that called you in the first place. Branches, such as JMP, BNE, etc., do not affect the stack, but of course they can send you somewhere incorrect unless your code is correct. There are certain tricks to be played with pushin and pulling RTS values to and from the stack, but it doesn't sound like you'd be up to that, so I'd follow the rules. Interrupts also use the stack for similar reasons, and the RTS equivalent is RTI. It *really* helps to have a trace mechanism, I'd recommend you to use the Altirra emulator and it's absolutely fantastic debugger. *edit* sorry hadn't read your post above while I was editing.

I think SIO or PBI is the way to go here. SIO would be slow for graphics, but fast enough for text, and much easier to implement than PBI. You'd have you write your own hack for E: and S: intercepts, but that would probably be easier than a PBI interface. Implement your own little interface commands to the PI side to send each char with the appropriate command context. Then the PI side would interpret the chars and commands. In fact, what you'd need on the PI side would be basically a telnet program that reads from the serial port and interprets characters based on the Atari 'terminal' type. I bet there's a telnet core somewhere you could modify. So, hack the E: and S: drivers appropriately to intercept each char, send it to the SIO connection, and stand up a serial program/modified telnet on the PI side. You have to add code such that the PI side responds to basic SIO commands, but that's very easy. With PBI, you could in fact implement your PI as a kind of external video card, which would be very cool but probably much harder to do. I have no idea what would be required electrically to hook the PBI up.

Do you need a reason? I never seem to.

I just ordered 2.

I hope so too. I for one would be willing to prepay if that would help.

bah, reading fail. Morel, the answer is yes as far as I can tell.

Jon, this is some amazing work. You continually impress me.

Maybe you shouldl say what you're willing to pay?

Atari programming is hard and time consuming, like all programming, but does not pay well. Since people need to work otherwise, it is hobby status. Since most of us have families and other hobbies, that gets sliced down even further. If I were retired, I would be a LOT more productive. I plan to do exactly that as soon as I can retire, which looks to be 5 or 6 years from now.

Good lord, are you guys arguing about opcodes again...this is really getting old. And Oh, Nice job, OP. I like the editor.

Actually, I thought you were talking about interpreted BASICs. Reading comprehension fail. Still, comparing a high level compiled language to a macro assembler is still kind of a stretch, but carry on.