From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2004-05-27 08:46:09
On Wed, May 26, 2004 at 03:32:09PM -0500, Jim Brain wrote:
> 00 LISTEN 0000 0000 0000 0010 (assuming 31-0 placement).
It is 32 bits, not 16. But yes, the command looks like that.
> I know from your earlier email you don't escape the 0's, but I feel that is
> much less elegant. The stream protocol then becomes "escape all 0 bytes,
> EXCEPT in the following circumstances"
I see, you would prefer to have clean layers in the protocol. Instead of
escaping of 00 payload bytes, you would like to escape 00 bytes also in the
parameters of commands. I don't know what you would achieve with that.
Of course, there must be a resynchronization mechanism, in case of
intermittent communications failure. I'm using the BREAK condition as a
signal to reset the microcontroller to idle state.
> 00 is problematic as an escape char, as it has a high distribution in
> data streams, (ff is not a best choice either, I was carrying over my
> telnet protocol work I had been working on. It probably should be an
> unused or JAM opcode that is not in the normal PETSCII or ASCII matrix
> (something above 127), and is not a common screen code. In other words,
> a byte with a low incidence of occurence in a normal stream.
I didn't consider that, because I have the feeling that the serial bus is
slower than the 38400 bps line. Most executable programs for the
Commodore 64 have been compressed, and there are no long sequences of zero
bytes. I picked zero as the escape byte, because testing against zero is
easy on the AVR. Testing against some other constant requires that the
value is loaded to one of the registers 16..31.
> I like your idea of sending ATN as a command, as that allows the PC to
> react quickly to it getting fired (Does anyone what happens on the bus
> when you are loading a program and RUN-STOP RESTORE is hit? DOes the
> CBM unit send an ATN low? Or, does the 15XX byte send just timeout?)
I think that the NMI handler in the Vic-20 or C64 simply releases the
serial bus lines, if it touches the serial bus at all. So, the drive
would just time out. But I haven't checked this.
> As I do. Although, even for your project, an ATMEGA8, which has 4 times
> the memory, shows as the same price as a 90s2313, and is a comparable
> pinout (it is a big bigger, at 28 pins, but still skinny DIP or PLCC
> formats).
I would like to make it possible to upgrade existing C2N232 units, and to
save trouble in circuit board design. You're right, there's no need to
stick to a smaller controller. But I like challenges, and I'm not yet
hitting the limits of the 2313 too hard. (Are you familiar of Levente
Hársfalvi's RS-232 to 1351 mouse adapter done with a PIC? That's a real
challenge.)
> My project hopes to include Ethernet on board, so having a
> complete app running onboard would be a big plus.
10 years ago, I was dreaming of something similar: a programmable device
for the serial bus. Currently available microcontrollers are making the
dream possible at an affordable cost.
> I could try. I was waiting a bit until I put the JDos routines in
> before I laid out the diagram in a package, to make sure I actually
> capture all of the relevant states.
It'd be good to draw one diagram without JDos and another including it.
> I am still unsure what happens when you try to load a file that does not
> exist. I assume the listen and talk happens, but when the line turns,
> what does the 1541 send? Does it just do nothing?
What does ?ST say after such a failed LOAD attempt?
> That is what I am doing now, and the 64 seems to respond with
> "File not found" like it should
I managed to get that as well. My firmware would do the talk-attention
turn-around handshake and wait for data from the RS-232 line. When I
told the C2N232 to simply release the bus and go to idle mode, the
Commodore would report ?FILE NOT FOUND. I don't remember if I checked
whether the ST bits were the same as with the 1541.
> As well, Is there ever a case where a command would be longer than
> 1 byte and would have an EOI sent?
I don't think that there is EOI handshake for bytes sent under ATN.
I concluded this after reading the VIC-20 KERNAL routines. Come to
think of it, EOI handshaking for ATN would make things very complicated
when you're talking to multiple devices. And there is no EOI handshaking
for the first ATN byte, is there?
On Wed, May 26, 2004 at 01:24:52PM -0500, Adrian Gonzalez wrote:
> Just wanted to let you guys know I'm following the discussions on C=
> hackers but it's been a pretty busy week both in and out of
> work. Hopefully I'll be able to try to debug the c2n232 over the weekend.
No problem.
> As for protocols between the AVR and the big computer, I was thinking about
> doing something more 'packet' based. Like a header that specifies options
> (atn, eoi, etc), length, maybe a checksum and then the payload.
I did have a design like that, but it simply doesn't work for the serial bus.
The GET# command wouldn't work, as it sends TALK and UNTALK for every byte
received. There's no way you can know the length of a transmission in
advance.
> The other thing that occured to me, and I had talked to Jim about, was
> implementing the standard IEC protocol using a CPLD, perhaps with JD and
> burst thrown in. I'm sure it could be done in a $2-ish CPLD. That way the
> avr would just read complete bytes out of the CPLD, which could be
> instructed to speak the different protocols as needed. Of course, at this
> point this is also another random idea that popped up in my head...
There are even microcontrollers with integrated CPLD. That could be an
option, although I'd say it's overkill. :-)
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.