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

[tschak909]

#FujiNet the next step in CIO integration is to attempt to create TCP connections. This is going along quite well. More soon.

Sent from my SM-G920F using Tapatalk

[E474]

Hi,

 

   Would this project benefit from including a supercapacitor so that it could work through a power cycle? There's more info in: 

 

but I'm not enough of a hardware hacker to see how appropriate this would be.

[tschak909]

thoughts, @mozzwald @jeffpiep?

 

-Thom

[mozzwald]

10 hours ago, E474 said:

Hi,

 

   Would this project benefit from including a supercapacitor so that it could work through a power cycle?

Not really sure if there would be a benefit. FujiNet boots before the Atari does, unlike the Raspberry Pi which takes a long time. Wifi connection can take longer (a couple seconds or less) to get going, no where near the time it takes a Raspberry Pi to boot. We can boot from internal SPIFFS first, then load ATR over network by selecting it from the Atari (diskulator example). It's certainly possible to add the supercap, I just don't know if it's worth it. Maybe someone else has an idea or use case for it. You can also power the FujiNet from microusb.

[Mr Robot]

I made a PiZero Hat with a Supercap on it from the topic above and it worked great, I did the same thing for the SDrive Max and I didn't think it added any real utility. Sure it kept the SDM alive through a power cycle but there's no reason you need to so it seems a bit pointless. 

 

If the Fujinet has non-volatile settings, is there any reason to keep it alive for ~20 seconds after power off?

 

[tschak909]

Nope.

Sent from my SM-G920F using Tapatalk

[tschak909]

At this moment:

 

* We are spinning the next revision of the board for testing among those of us working on the hardware. 
* Mozzwald is experimenting with making #FujiNet work with MidiMaze with a special mode that utilizes the SIO clock line, code is here: https://github.com/mozzwald/FujiNet-MIDIMaze
* Jeff Piepmeier is working out the kinks for an ESP32 based version of the hardware, to investigate the expanded I/O capabilities.
* I am taking the first steps to write a CIO handler. I am prototyping it in CC65, so that I can concentrate on logic.

On the last point, if there are any in the ABBUC who have insight into writing a CIO handler, I need to hear from you. I am having difficulty making CIO GETREC work properly, and need to understand its behavior, as well as other bits of behavior that are otherwise not documented, because at the moment, I am literally writing small tests, and observing their behavior by writing test programs in BASIC.

But to answer the question, can you write a CIO driver in CC65? yes. Is it efficient code? no. but that's okay, once it is written, it can be translated to assembler by someone more competent.

 

-Thom

[E474]

Hi,

 

   I just mentioned this as I watched the video (very informative), and one of the comments during the video was about using external power during a power cycle, which is when I wondered if adding a supercapacitor would be a good idea.

 

    Also, I had a quick look at the diskulator (?) sources, and saw you were using #$70 for DDEVIC, but I thought this was being avoided as it clashed with the SDrive, but I am not sure if this is the same functionality anyway? It's a pity that the SDrive code can't be unified as there is probably some functional overlap.

 

  I was also wondering how easy it would be to implement the code on a Raspberry Pi Zero (or anything else), as apart from some of the SDrive devices, most of the devices hosting ATR images also have network connectivity, so should be able to provide N: device capability?

 

   Glad to see this project making progress!

[tschak909]

These are all things that can be explored.

 

The DDEVIC isn't set in stone, yet..  as we are still very much just trying to implement test functionality.

 

If someone wants to implement said functionality on a Pi, go right ahead. The reason I didn't go this route is simply that the RPi, even when you write code to run directly on the VC4 GPU, still has a noticeable boot-up time, most so with Linux, which, the fastest I've been able to do a bring-up on a Pi with Linux and a highly streamlined kernel (based on LibreELEC and stripping EVERYTHING to the bone), is roughly 4 seconds.

 

The 8266 and ESP32 come online and start executing firmware code, much faster.

 

[tschak909]

OK, I need some help by those who KNOW CIO:

 

I never see a PUT RECORD command in my IOCB.. so..

 

when a PUT RECORD is sent, is that transformed into a bunch of CIO PUT calls for a single byte in A?

 

-Thom

[AtariGeezer]

You need to Open a Device before use...

[tschak909]

Yes, am aware of that. Device is opening correctly.

 

-Thom

[AtariGeezer]

I guess the current code isn't posted yet?

 

In main.c it only shows:

void cio_open(void)
{
}

 

[tschak909]

nope, let me push.

-Thom

[tschak909]

pushed.

-Thom

[tschak909]

for reference, here is the entire P: handler in ROM:
 

;		 ************************
;		 PRINTER HANDLER ROUTINES
;		 ************************
;
;
;
;
;
;		 PRINTER HANDLER STATUS ROUTINE
;
PHSTAT: LDA	  #4
		  STA	  PBUFSZ		;SET BUFFER SIZE TO 4 BYTES
		  LDX	  PHSTLO
		  LDY	  PHSTLO+1	 ;SET POINTER TO STATUS BUFFER
		  LDA	  #STATC		;SETCOMMAND TO "STATUS"
		  STA	  DCOMND		;SET STATUS COMMAND
		  STA	  DAUX1
		  JSR	  SETDCB		;GO SETUP DCH
		  JSR	  SIOV		  ;SEND STATUS COMMAND
		  BMI	  BADST		 ;GO IF ERROR
		  JSR	  PHPUT		 ;YES, PUT STATUS INTO GLOBAL BUFFER.
BADST:  RTS
;
;
;
;
;		 PRINTER HANDLER OPEN ROUTINE
;
PHOPEN: JSR	  PHSTAT		;DO STATUS COMMAND TO SIO
		  LDA	  #0
		  STA	  PBPNT		 ;CLEAR PRINT BUFFER POINTER
		  RTS
;
;
;
;
;		 PRINTER HANDLER WRITE ROUTINE
;
PHWRIT: STA	  PTEMP		 ;SAVE ACCUM
		  JSR	  PRMODE		;GO DETERMINE PRINTMODE
		  LDX	  PBPNT
		  LDA	  PTEMP		 ;GET CHAR. SENT BY CID
		  STA	  PRNBUF,X	 ;PUT CHAR. IN PRINT BUFFER
		  INX					  ;INCR. BUFFER POINTER
		  CPX	  PBUFSZ		;BUFFER POINTERBUFFER SIZE?
		  BEQ	  BUFFUL
		  STX	  PBPNT		 ;SAVE SUFFER POINTER
		  CMP	  #CR			;IS CHAR. = EOL ?
		  BEQ	  BLFILL		;IF YES, GO DO BLANK FILL.
		  LDY	  #SUCCES	  ;PUT GOOD STATUS IN Y REQ FOR CIO.
		  RTS
BLFILL: LDA	  #SPACE		;PUT BLANK IN ACCUM.
FILLBF: STA	  PRNBUF,X	 ;STORE IT IN PRINT BUFFER.
		  INX
		  CPX	  PBUFSZ
		  BNE	  FILLBF		;BUFFER BLANK FILLED?
BUFFUL: LDA	  #0
		  STA	  PBPNT		 ;CLEAR PRINT BUFFER POINTER
		  LDX	  PHCHLO
		  LDY	  PHCHLO+1	 ;SET POINTER TO PRINT BUFFER
		  JSR	  SETDCB		;GO SETUP OCR
		  JSR	  SIOV		  ;SEND PRINT COMMAND
		  RTS					  ;YES.
;
;
;
;
;		 PRINTER HANDLER CLOSE ROUTINE
;
PHCLOS: JSR	  PRMODE		;GO DETERMINE PRINT MODE
		  LDX	  PBPNT
		  BNE	  BLFILL
		  LDY	  #SUCCES
		  RTS
;
;
;
;
;
;
;
;
;		 S U B R O U T I N E S
;
;
;
;
;
;		 SET UP DCB TO CALL SIO
;
SETDCB: STX	  DBUFLO
		  STY	  DBUFHI		;SET BUFFER POINTER
		  LDA	  #PDEVN
		  STA	  DDEVIC		;SET PRINTER BUS I.D. FOR DCB
		  LDA	  #1
		  STA	  DUNIT		 ;SET UNIT NUMBER TO 1
		  LDA	  #$80		  ;DEVICE WILL EXPECT DATA
		  LDX	  DCOMND
		  CPX	  #STATC		;STATUS COMMAND?
		  BNE	  PSIOC
		  LDA	  #$40		  ;EXPECT DATA FROM DEVICE
PSIOC:  STA	  DSTATS		;SET SIO MODE COMMAND
		  LDA	  PBUFSZ
		  STA	  DBYTLO		;SET LO BYTE COUNT
		  LDA	  #0
		  STA	  DBYTHI		;SET HI BYTE COUNT
		  LDA	  PTIMOT
		  STA	  DTIMLO		;SET DEVICE TIMEOUT COUNT
		  RTS
;
;
;
;
; GET DEVICE TIMEOUT FROM STATUS & SAVE IT
;
PHPUT:  LDA	  DVSTAT+2
		  STA	  PTIMOT		;SAVE DEVICE TIMEOUT
		  RTS
;
;
;
;
; DETERMINE PRINT MODE & SETUP PRINT BUFFER SIZE, DCB PRINT
; COMMAND, &. DCB AUX1 FOR PRINT MODE
;
PRMODE: LDY	  #WRITEC	  ;PUT WRITE COMMAND IN Y REG
		  LDA	  ICAX2Z		;READ PRINT MODE
CMODE:  CMP	  #N
		  BNE	  CDUBL		 ;PRINT NORMAL ?
		  LDX	  #NBUFSZ	  ;YES, SET NORMAL CHAR. BUFFER SIZE
		  BNE	  SETBSZ
CDUBL:  CMP	  #D
		  BNE	  CSIDE		 ;PRINT DOUBLE?
		  LDX	  #DBUFSZ	  ;YES, SET DOUBLE CHAR. BUFFER SIZE
		  BNE	  SETBSZ
CSIDE:  CMP	  #S			 ;PRINT SIDEWAYS ?
		  BNE	  GOERR		 ;IF NOT, GO TO ERROR ROUTINE
		  LDX	  #SBUFSZ	  ;YES, SET SIDEWAYS BUFFER SIZE
SETBSZ: STX	  PBUFSZ		;STORE PRINT BUFFER SIZE
		  STY	  DCOMND		;STORE DCB COMMAND
		  STA	  DAUX1		 ;STORE DCB AUX1 PRINT MODE
		  RTS
GOERR:  LDA	  #N			 ;SET DEFAULT PRINT MODE TO NORMAL
		  BNE	  CMODE

 

[tschak909]

welp, found the problem, once again, BASIC and compiler fighting each other, so I had to move the ZP area down further to $E5

 

Changes pushed. writing now works.

 

Wow, that was five hours of @#(%@#%#@

 

-Thom

[AtariGeezer]

void _cio_open(void)
{
  char *p=(char *)OS.ziocb.buffer;

  // remove EOL
  p[OS.ziocb.buflen-1]=0x00;

  // Scoot buffer past the N:
  p+=2;

  // Copy into packet
  strcpy(packet,p);
  
  // I am ignoring the aux1/aux2 for this test, and simply assuming the open parameters.

  OS.dcb.ddevic=0x70; // Network card
  OS.dcb.dunit=1;     // device unit 1
  OS.dcb.dcomnd='c';  // Do a connect
  OS.dcb.dstats=0x80; // Write connect request to peripheral.
  OS.dcb.dbuf=&packet; // Packet
  OS.dcb.dbyt=256;     // packet size
  OS.dcb.dtimlo=0x1F; // Timeout
  OS.dcb.daux=0;      // no aux byte
  siov();

  // Clear buffer
  memset(&packet,0x00,sizeof(packet));
  
  ret=err=OS.dcb.dstats;
}

The code above is what would be used from the user side of opening a device, not useful in the Handler...

Think I posted some code of the SX-212 handler in the Sio2wifi thread...

[tschak909]

I've gotten it to work, it turns out that the zero-page allocation used by CC65 was trouncing over yet some more locations that BASIC was using for ferrying data back and forth between CIO. Scooted it forward, and it works.

 

...i'm going to ignore what you just said, because you seem to be misunderstanding where the CIO part of the handler is vs the SIO code that's in the arduino firmware.

 

 

-Thom

[tschak909]

And here it is working, all changes have been pushed.

 

I will write a readme showing how to use the test shortly, in the mean time, here's a video:

 

What happened?

 

BASIC was fighting with CC65 again in the zero page. Solution was to further move up CC65's ZP registers.

 

-Thom

[AtariGeezer]

4 hours ago, tschak909 said:

you seem to be misunderstanding where the CIO part of the handler is vs the SIO code that's in the arduino firmware.

-Thom

Okay, in the Printer handler, it does a S)tatus call to determine if it's Open and you are using a custom c)onnect call to check if it exists.

I see...

Edited November 27, 2019 by AtariGeezer

[Bill Lange]

Here is my testing of Thom's "CIO2 Test Program".

 

I create a short BASIC program that sends a message through FujiNet to port 23 on a server that has Hercules running and listening. 

 

 

[tschak909]

VintageIsTheNewOld just posted about #FujiNet! 

https://vintageisthenewold.com/fujinet-atari-8-bit-network-adapter/

[tschak909]

 

Slowly but surely, TCP is taking shape, in this screenshot you see setting up a listening socket, accepting an incoming connection from that socket, getting the # of bytes available to fetch from that socket, and doing a CIO input from data on that socket.

 

Still a lot to work out, but it's starting to work.

-Thom

[tschak909]

Here is a test harness that I am writing in BASIC for the N: handler. It is a simple line driven direct chat program which I call TINCANS. I wrote a version of this for the ZX Spectrum Spectranet interface, as well, for the same reason: to show how easy it will be to write network programs with #FujiNet!

Sent from my SM-G920F using Tapatalk