danwinslow

Uh...what. It would be difficult to be further from the truth than that. That's like saying a crocodile is a kind of dog, because they both have four legs.

Yes, the 'where was I loaded from" thing is pretty tricky. I never did find a universal solution.

I hear you. I wasn't planning on it. The Dragon Stack will need at most 2 banks of ext ram. Less, or none, if all you want is fast UDP.

I plan on *writing* software for this. New software is mostly the point, I think.

I Want two, please.

The real lesson here is a successful computer is an architecture, not a set of chips, in the same way a successful software framework is a collection of patterns, and not a specific application.

Wow /salute

Its too damn easy, so I'm glad to hear about a tougher mode.

telnetd...the 'D' means its a server and not a client. OK, I'll get a test system to you in a couple weeks.

Did you mean the Contiki one, or were you using one of my old dos ones? I'm getting finished rewriting the stack for Atari dos's, so I can def put you on the tester list.

I have a serious lust for Falcons for some reason. At one point I had 6 of them, and 3 CT63's. Still have 2 left, and some odd parts and pieces. I've been forcing myself to sell them, slowly, because I just don't use them and I don't have time to program them the way I would want to.

Yeah, that would be great. You'd need some buffering on the board, say a meg of some kind of ram, and a small PIC or something to run the buffering and manipulate the interface with the atari. I can write the software, I just don't know crap about hardware.

You know, I think a really high speed serial interface would be interesting. The reason I haven't done a lot of serial integration with like ethernet boards and stuff is that SIO is just really slow. I tried it, but even specially jacked up via high speed SIO's its really still too slow for something like a UDP ethernet stream or a USB connection. Having to poll SIO for stuff happening is really a drag. If we had a PBI board that did high speed serial and implemented a custom IRQ or something, then it would be a lot more doable, and woul dopen up a whole world of possible integrations.

You tell me. Some kind of IO card comes to mind, bluetooth, USB, maybe ethernet, etc. A guy can dream.

I'm sure he knows that the interest is high and will remain so.

This is not an 'interest thread'. Nobody, as far as I know, is watching this in terms of reserving copies or planning production.

We have GOT to do something with that. I wish I had hardware skills. *edit* I hereby offer to bankroll somebody who wants to make an adapter board of some sort.

So...I've been trying to find some info/schematics for the pinouts available on the Incognito...is there a board schematic somewhere that I've missed? Is the interface at the top that looks like an IDE plug actually IDE or is that the PBI? What else is available on the board for pinouts? *edit* Also, does anyone know where I can find some info about PBI programming, or example source code? *edit++* found this old article, interesting stuff and some source code: http://www.oocities.org/dr_seppel/

I have an XIO set up to return number of chars available. I'm using status to dump some tables for an IPCFG and an ARPCFG command.

Hehe, yeah Ken. It's most similar to an INPUT reading from a keyboard...it's not EOF, its just the person hasn't typed anything yet. I've made the routine called by BASIC on an input to a TCP channel behave exactly that way. The only way it generates a 136 EOF error is if the channel gets closed while its blocking on input. Seems to work fine.

On an INPUT, what am I expected to do when there isn't a character available yet? Am I supposed to block reading that 1 char until I get one? I am assuming so.

Yes, that's what I was saying...as long as it's got io mapped to PBI or the memory bus. But NO VBXE, thats going way too far!

Hehe, well not too much more complicated, except that I wanted a non-EOL sensitive behavior too, as in like a binary PUT. And this is in reference to a TCP stream connection; for UDP all you would have would be the binary put, and you'd get a packet for each put you called.

regular IOCB is wrong, too. There does seem to be a check for OPEN and direction settings. Jon - it does, but my issue is deciding when to actually send a packet. For 'record mode' PRINT, I would want to send a packet when EOL ($9B) is encountered. That's what I wanted ICCOM for, to tell which mode I was in. It's not a big deal, I can switch to XIO if needed, and PUT doesn't work right from basic anyways.

You guys are awesome. Thanks, I was kind of suspecting BASIC...I'm just going to go with XIO calls.