Jump to content
IGNORED

#FujiNet - a WIP SIO Network Adapter for the Atari 8-bit


tschak909

Recommended Posts

CR/LF processing is still on my list to deal with, it's more complex because I have to abstract the status call slightly to go ahead and pre-fetch the buffer and ripple through the buffer removing the extra characters as a result of CR/LF.

 

It's not critical at the moment, as I have much more pressing matters to deal with (how to properly handle interrupts, has anyone here any experience in dealing with 6520 edge detected interrupt transitions?)

 

-Thom

Link to comment
Share on other sites

It's wouldn't be necessary if the connection was raw on both ends, or an extremely configured telnet on both ends. Telnet is not transparent though... there is always f*ckery unless telnet is forced into binary mode.

 

as I saw what I believe to be the telnet handshake at startup... well that's the BBS's offered connection, if it's a PC then ICE-T XE or similar would be the answer.

 

None of this really matters at this moment in time though... that can be fleshed out later... more important things to deal with.

Link to comment
Share on other sites

yes, IAC can be abstracted, this is actually what a telnet protocol module would take care of (it would inherit from networkProtocolTCP), we'll get there. 

 

Right now, I am trying to work out the interrupt timing and acknowledgement, in such a way that it's slow enough for BASIC. ;)

 

PLATOTERM can deal just fine with a storm of IRQ's, BASIC not so much. (it was actually causing key clicks to change pitch), so I need to just slog it out...going to take some time, but could really use some insight from ppl who have actually used the interrupts on the PIA.

 

-Thom

Link to comment
Share on other sites

On a side note, rattling around in my head (could remember something wrong), in order to sync an external clock with the pokey and phi... I think a 74LS74 needs to be put on the clock coming from the fujinet to the external clock in, and the sio clock out from the Atari must be sent to the 74LS74... in that way it only allows a transition to be accepted when it will be valid and not generate extra pulses...  I don't think it creates a feedback loop... if it does then a modification would have to be in  the Atari itself using phi to the ls connected to the  external in

 

when dealing with the added delays of pokey / pia and then finally the 6502 three names come to mind.

@HiassofT, @ijor, @Rybags, and on theoretical level @candle. The man who could explain what everyone has to say would be @phaeron...

 

but your dealing in basic, we can still us peak to get keys... maybe useful... didn't look at your quick and dirty terminal basic listing, I should go back and look...

 

from a book on basic... etc.

Most of the time, whatever number is stored in location 53769 is also stored at 764. There are exceptions when the key combination is acted on during an interrupt. The CONTROL-1 combination, for instance, is read during an interrupt and can't be read from 764—but the value still occurs at location 53769 and can be read there. On XL models, CONTROL-F1, CONTROL-F2, CONTROL-F4, HELP, SHIFT-HELP, and CONTROL-HELP also generate codes that are not transferred from 53769 to 764.

What difference does this make? If you want to be able to read that code in spite of the interrupt, you can—by reading 53679 (actually, 53769) instead of 764. The interrupt will still take place, but your program will also "know" that the key combination was pressed. Or if you want your program to ignore keys used by the interrupts, read the values at 764 instead of 53769.

Here is a short program that reads the hardware register and POKEs the raw KEYCODE number into screen memory. First, you will see that the KEYCODE number has no relation to the ICODE number that normally is POKEd into screen memory.

Second, since the PRINT command isn't being used, the CONTROL-1 key has no effect at all—and its KEYCODE number is POKEd into screen memory, where it appears as an inverse question mark. If you have an XL model, you will see that pressing CONTROL-F4 still toggles between the standard and international character sets—but it also causes an inverse 4 to appear on the screen.

10 POKE PEEK(88)+256*PEEK(89)+N,PEEK(53769)
20 N=N+1-960*(N>958):GOTO 10

Built-in delay. There is a slight but measurable time lag between the keypresses causing a number to be stored at 53769, and the echo getting stored in 764. Here is a very short example program that will show you these codes:

10 PRINT PEEK(764);" ";PEEK(53769)
20 FOR I=0 TO 40:NEXT I: GOTO 10

This program PRINTs the value at 764 on the left and the value at 53769 on the right. If you RUN this program and then type very quickly, you will sometimes see a number appear on the right that has not yet appeared on the left—you have caught the OS between receiving the KEYCODE at 53769 and echoing it at 764. If your program needs speed (particularly if it is a machine language routine), you'll definitely want to read the keyboard code at 53769.

 

**** I'm sure you know all of this, but I wondered if it would get around the interrupt storm blocking your key presses...

Edited by _The Doctor__
Link to comment
Share on other sites

I can't remember if I played with PIA interrupts (interrupt and proceed lines on SIO) before, glancing through the PIA datasheet and Atari OS source code it should be pretty straight forward.

 

If PIA is configured to handle interrupts, i.e. bit 5 of PACTL/PBCTL set to 0 (input), bit 4 to edge polarity and bit 3 to 1 (IRQ enable) then PIA will assert the IRQA/B lines (which are connected to the 6502's IRQ input) whenever the configured edge is detected.

 

The IRQ line will stay asserted until PORTA/B are read. So the PIA acts as a latch, translating edge-triggered interrupts to level triggered ones.

 

The IRQ handler in the OS already takes care of that, it checks bit 7 of PACTL/PBCTL (which signals that the PIA asserted the IRQ), read PORTA/B (which clears that bit and deasserts IRQA/B) and then calls the corresponding interrupt vectors VPRCED ($202) or VINTER ($204) which by default do nothing (PLA/RTI).

 

So you can simply hook into these interrupt vectors and for example set a flag in memory (LDA #1, STA GOT_IRQ, PLA, RTI) which you can then check via a CIO/XIO call from your program.

 

It might be best to let that CIO/XIO call auto-clear the bit, or you could do that when you issue the SIO commands to react on the interrupt condition (eg retrieve the receive buffer).

 

As it might take the program a bit to check for IRQ assertion (it could be busy doing something else, or might only check every frame or so) and also the whole SIO roundtrip takes quite a bit of time it might be best to rate-limit generation generation of the interrupt edges in fujinet.

 

eg when some data is available for the first time generate a 50us or so low pulse on the SIO interrupt or proceed line. I chose 50us because that's about the length of a bit at standard ~19kbit rate and that should be received well on the Atari side even if there's capacitive load on the SIO lines. Then repeatedly check eg every 100ms or so if there's still data in the buffer and if yes generate another pulse.

 

It might be easiest to implement that via a timer (if you have one available), if the timer is running it means interrupt conditions are already sent, if it's not running then create an edge and start the timer. The timer routine can then simply disable itself when eg the whole receive buffer has been retrieved.

 

so long,

 

Hias

  • Like 3
Link to comment
Share on other sites

Yup, that's pretty much what I've been doing.. I'll try rate limiting to roughly 100ms. I don't think i'll need to waste a timer. :) Thanks @HiassofT :) (Your high-speed SIO code is amazing)

 

could we adjust the HSIO code so that devices in the 0x7X range also get high-speed? :)

 

-Thom

Edited by tschak909
  • Like 2
Link to comment
Share on other sites

(by wasting a timer, I meant a POKEY timer)

 

And yes, looks like a nice 100ms rate limiting did wonders. It turns out I was sending interrupt pulses so fast that I was executing the ISR on the Atari side so many times, that I was adversely affecting the pitch of the key-click :) Wheeeee :)

 

Okay, so with that I think interrupts are working correctly, and I am going to debug the UDP protocol module. The test program there will be the game of Tic-Tac-Toe that I whipped together in December, the difference is that instead of doing the SIO calls in BASIC (which made for some very verbose code), it will be using the CIO and standard I/O commands to send and receive UDP packets, which will make the code much smaller.

 

(for a bit of detail, I was initially trying to implement an interrupt acknowledge SIO command to set the interrupt flag again once something had been received, which added quite a bit of complexity which would have either had to have gone inside the user program, or inside the CIO handler... this way of simply rate limiting the interrupt pulses is much more efficient and makes sure we don't miss any events.)

 

-Thom

 

 

Link to comment
Share on other sites

3 hours ago, tschak909 said:

could we adjust the HSIO code so that devices in the 0x7X range also get high-speed? :)

Not easily. Extending the code would be no big problem but then it won't fit into the very limited ROM space.

 

However it should be possible to provide an official entry point to the highspeed code in ROM (that bypasses the device check).

 

I already include a unique signature with version and date (eg "Hias 1.31 200411" in my current testing version) in the last 16 bytes ($CFF0-$CFFF) so you can check for presence of my highspeed code in ROM, verify that the version is recent enough (eg 1.31 and below won't have that entry point) and then use it (at your own risk :) 

 

I was thinking about "set A to the desired highspeed variant, eg 3 for pokey divisor 3", then call the entry point like standard SIO.

 

$CFED might be a good location for that entry point but I'll need to think about that a bit and also re-shuffle things a bit ($CFED is currently used, EE and EF seem to be free).

 

so long,

 

Hias

  • Like 1
Link to comment
Share on other sites

1 hour ago, tschak909 said:

(by wasting a timer, I meant a POKEY timer)

I was thinking about a timer in fujinet, but it seems you already have things working so that's a bit moot now :)

 

BTW: you may need to be prepared for the proceed/interrupt getting occasionally "lost". Anything that reads from PORTA/PORTB (eg joystick handling in VBI or programs fiddling with PORTB to access extended memory) will clear the interrupt bit in PACTL/PBCTL. Even if a program has IRQs enabled things may get missed. So having a timer in fujinet code that creates periodic notifications may be a good thing, eventually the notification should get through.

 

so long,

 

Hias

  • Like 2
Link to comment
Share on other sites

6 minutes ago, HiassofT said:

I was thinking about a timer in fujinet, but it seems you already have things working so that's a bit moot now :)

 

BTW: you may need to be prepared for the proceed/interrupt getting occasionally "lost". Anything that reads from PORTA/PORTB (eg joystick handling in VBI or programs fiddling with PORTB to access extended memory) will clear the interrupt bit in PACTL/PBCTL. Even if a program has IRQs enabled things may get missed. So having a timer in fujinet code that creates periodic notifications may be a good thing, eventually the notification should get through.

 

so long,

 

Hias

yup, I'm using esp timer 0 for now. It will be shared by the ATX code most likely (I don't think they'll both be running at the same time).

 

This really is all sorts of awesome, we actually have an Atari peripheral using the interrupt lines for their intended purpose! :)

 

-Thom

Edited by tschak909
  • Like 1
Link to comment
Share on other sites

Real life has taken me away from the Atari scene for a few months, but I just wanted to chime in and say how cool this project is.

I really want to get my 800xl connecting online somehow and play around with IRATA.ONLINE soon.

  • Like 3
Link to comment
Share on other sites

14 minutes ago, manterola said:

Are changes to the assigned io pins to sio (DIn , DOut, etc.)permanent? I would like to know, because I will need to modify my homemade interface...

I think the changes are not yet in the firmware since I can still run the latest version. right?

The changes are only required for the WROVER module at this point. All previous hardware is based off the WROOM module (what you probably have). The change requires modifying a file in the platformio core manually and I've added this to the instructions on the wiki.

 

https://github.com/FujiNetWIFI/atariwifi/wiki/Board-Bring-up-for-PLATFORM.IO-code#fix-for-fujinet-with-wrover-module

  • Like 1
Link to comment
Share on other sites

21 hours ago, HiassofT said:

However it should be possible to provide an official entry point to the highspeed code in ROM (that bypasses the device check).

 

I already include a unique signature with version and date (eg "Hias 1.31 200411" in my current testing version) in the last 16 bytes ($CFF0-$CFFF) so you can check for presence of my highspeed code in ROM, verify that the version is recent enough (eg 1.31 and below won't have that entry point) and then use it (at your own risk :) 

 

I was thinking about "set A to the desired highspeed variant, eg 3 for pokey divisor 3", then call the entry point like standard SIO.

 

$CFED might be a good location for that entry point but I'll need to think about that a bit and also re-shuffle things a bit ($CFED is currently used, EE and EF seem to be free).

@tschak909 could you give this highspeed patch version a try? https://www.horus.com/~hias/tmp/hipatch-200428.zip

 

I've implemented the entry point at $CFED as described above. The patch includes a "Hias 1.32" version identifier so you can check for the presence of the entry point.

 

I included some info in README.txt and also a "diag-entry.src" file that makes use of the entry point (I've used that for testing here).

 

so long,

 

Hias

  • Like 2
Link to comment
Share on other sites

12 minutes ago, HiassofT said:

@tschak909 could you give this highspeed patch version a try? https://www.horus.com/~hias/tmp/hipatch-200428.zip

 

I've implemented the entry point at $CFED as described above. The patch includes a "Hias 1.32" version identifier so you can check for the presence of the entry point.

 

I included some info in README.txt and also a "diag-entry.src" file that makes use of the entry point (I've used that for testing here).

 

so long,

 

Hias

ok, i'll try. my highspeed patch is in my U1MB as part of the HSIO PBI...need to see how to .... adjust accordingly :)

 

Thanks :)

 

-Thom

 

  • Like 1
Link to comment
Share on other sites

The U1MB PBI code would be a different route (I guess the "All" SIO devices selection should do it), the code I added is for patched XL OS ROMs.

 

Just use the patchrom.exe in the ZIP to create a patched XL OS and install it in one of the U1MB OS slots if you want to give it a try.

 

so long,

 

Hias

  • Like 2
Link to comment
Share on other sites

23 hours ago, HiassofT said:

Not easily. Extending the code would be no big problem but then it won't fit into the very limited ROM space.

I have actually done it for SIO2BT:

https://github.com/TheMontezuma/highspeed-sio/releases

The "standard" hi-speed device detection is preceded by sending get status to a device with a 3xSIO speed.

If an answer comes, we store the index for this device and we are done, otherwise we proceed with further checking.

Instead of having a fixed storage for hs-index for 8 drives, there is a round buffer storing hs-indexes for 4 last used SIO devices.

This way all SIO devices (and not only drives) are supported.

More info on github in updated readme.txt file.
@HiassofT

In my fork I extended your patch in a way to avoid conflicts with the original implementation, so if it is OK for you, consider to merge it back to your base code.

Edited by TheMontezuma
  • Like 1
Link to comment
Share on other sites

9 minutes ago, TheMontezuma said:

Instead of having a fixed storage for hs-index for 8 drives, there is a round buffer storing hs-indexes for 4 last used SIO devices.

U1MB PBI BIOS implementation works in a similar manner; 15 HS entries for disk drives, and a 4-element ring buffer for the HS indexes of other devices.

Link to comment
Share on other sites

2 minutes ago, flashjazzcat said:

U1MB PBI BIOS implementation works in a similar manner; 15 HS entries for disk drives, and a 4-element ring buffer for the HS indexes of other devices.

Sorry. I forgot to mention that the idea and implementation of the ring buffer come from you :)

Edited by TheMontezuma
Link to comment
Share on other sites

17 hours ago, mozzwald said:

The changes are only required for the WROVER module at this point. All previous hardware is based off the WROOM module (what you probably have). The change requires modifying a file in the platformio core manually and I've added this to the instructions on the wiki.

 

https://github.com/FujiNetWIFI/atariwifi/wiki/Board-Bring-up-for-PLATFORM.IO-code#fix-for-fujinet-with-wrover-module

Thanks! I did not realized the latest updated schematics where valid only for WROVER version of ESP32. 

I am sorry for the confusion.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...