Jump to content

tschak909

Members
  • Content Count

    5,996
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by tschak909

  1. It must be understood: If nobody TRIES to learn how FujiNet works underneath (or even looks at the sheer amount of content I am producing towards this subject) there will not be anyone who understands FujiNet internals well enough to be able to solve the problem. What you're saying, @Kyle22 is a gigantic cop-out. If everybody says the same damned thing, "I'll wait until somebody else does it." it never gets done. Do you not grasp that you're literally now trying to play the victim? Maybe you do. Maybe that's how you've gotten what you wanted. It's a shitty way to live life. -Thom
  2. Waaah, I don't understand FujiNet internals. ASK! Are you an invalid? -Thom
  3. You just aren't getting it, are you? Try to make something work. Everything is available. I AM NOT YOUR PERSONAL CODER. Especially not for something that only you will use. -Thom
  4. The RunCPM implementation provides drives 'A' to 'P' which are read directly from the SD card. Not only that, but the BDOS (and BIOS) can be extended, as it is a high level implementation, to add missing functionality. -Thom
  5. Yup, if needed, we could set up a gitlab instance somewhere. -Thom
  6. You will have to engineer one to fit on the Z80 socket, as such a beast does not exist (for the Indus GT) Seriously, at this point, the gloves are off. You do not listen to ANYONE, and for that, you're condemned to be forever spinning your wheels accomplishing nothing. and to be even more succinct. You do not listen to anyone who gives you a solution if it's not the one you specifically want. THIS is what dooms you to accomplishing nothing, because you absolutely refuse to admit that your viewpoint may be wrong, and that you might need to take another path. It's been YEARS of this shit, with you. YEARS of people trying to help you, give suggestions, and in every case when somebody has finally had it with you, you just recoil and turn into the victim, because, god, it probably worked for you in school at some point. You don't like Windows 10, fine. Windows XP is a massive security hole. More than a few of us gave solutions for an actual secure operating environment (especially because some of us including ME _ARE_ SECURITY EXPERTS WHO HAVE WORKED IN THE FIELD PROFESSIONALLY! AND ACTUALLY KNOW WHAT THE FUCK WE ARE TALKING ABOUT!), you just plugged your ears going LALALALA... It's not about security. You are not honest with yourself, and that is why you are doomed to failure. -Thom p.s. I guess this is a long way for me to go, blowing my top in the process, for me to say, dude, there are actual ways to accomplish what you want to do, if you only get your head out of your arse, and actually try to think about solving the problem, instead of just trying to do things a very specific way. I've shown you the path, and so many of us have bent over backwards to help for many things in the past, but dude. SACK THE FUCK UP.
  7. BYE.COM: https://github.com/FujiNetWIFI/fujinet-cpm-tools/blob/main/bye/src/bye.c The resulting hooks in BIOS: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/runcpm/cpm.h#L363
  8. with a Tektronix 4014 emulator, the TEK4014 GSX driver can be used, and a port of platoterm becomes possible (or any other GSX program) The 4014 protocol is well documented, and somebody sufficiently motivated (and not working on a dozen other related things in fujinet) could whip one up in a week. http://www.urbanjost.altervista.org/LIBRARY/libvogle/drivers/tek.html -Thom
  9. Case and point, the CP/M module in fujinet can be extended with more BDOS commands. I've done this to add fujinet functionality: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/runcpm/cpm.h#L829 https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/runcpm/abstraction_fujinet.h#L603 and suddenly, you're able to do the following from the Z80 side: https://github.com/FujiNetWIFI/fujinet-cpm-tools/blob/main/listen/src/listen.c This, coupled with the fact that CP/M usage is completely abstracted to the point where storage is only limited by the SD card space, this creates a better environment. Why are you wasting your time doing the dumbest approach possible? -Thom
  10. Your tenacity isn't what makes my eye twitch. it's that you spin your wheels doing the most wrong thing possible, while simultaneously ensuring you'll never find a workable solution by not listening to anyone with actual experience. There is something very....very wrong with you. -Thom
  11. In case it's not evident: You can build an #apple2 #FujiNet using the schematics for the Fujinet 1.0, or using a DevkitC on a breadboard and wiring it up to a DB19 connector according to the instructions in: https://github.com/FujiNetWIFI/fujinet-platformio/blob/iwm/lib/bus/iwm/iwm.cpp using the board bring-up instructions: https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Board-bring-up-for-FujiNet-Platform.IO-code and using the code in the IWM branch: https://github.com/FujiNetWIFI/fujinet-platformio/tree/iwm
  12. @Jeffpiep has been doing a lot of excellent work to bring the #Apple2 #FujiNet firmware up to speed for block devices. Shown here booting Total Replay v4 from the DigitalOcen cloud! More to come in the coming weeks!
  13. @Jeffpiep has been doing a lot of excellent work to bring the #Apple2 #FujiNet firmware up to speed for block devices. Shown here booting Total Replay v4 from the DigitalOcen cloud! More to come in the coming weeks!

     

  14. no problem, the easiest solution would be to have your disk drive be drive 2. -Thom
  15. Device slots on fujinet map directly to Dx: If you want, you can completely bypass config, and use fmount, fmall, fnew, etc to create and mount images to D2: while keeping the 1050 to D1: He can also remap the 1050 to D2: and boot the fujinet using config.
  16. You're not LOOKING for a solution. You're LOOKING for someone to HAND you a solution. Difference. -Thom p.s. I am getting _VERY_ tired of people unwilling to come out of their comfort zone to roll up their sleeves and figure out what can solve their problems, working the problem one piece at a time. No, they're expecting the few of us working on the code to just magically cook up a solution for something only those with the problem want or understand. If you want it, PLEASE... do the elbow grease and try to work the problem. It is workable. -Thom
  17. The FujiNet device is always available. It is SIO device $70. This is literally why the fnc-tools work! The FNC tools are on atari-apps.irata.online in fnc-tools.atr. They can run in ANY DOS. The source code for them is here: https://github.com/FujiNetWIFI/fujinet-config-tools And the SIO commands are documented here: https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Commands-for-Device-ID-%2470 On top of all of this, in the web admin, the config program can be completely disabled, and just the tools used instead. I've documented this, I've shown this, but nobody seems to pay attention. I have spent, so much time, trying to show everybody all of this stuff, but it falls on _very_ deaf ears, as the same people say the same things over and over, even after I explain this stuff. Is it not making any sense? -Thom
  18. it is extremely presumptuous for you to think that we would already know how to make this work. -Thom
  19. @rcamp48 I am glad you were able to put something together. -Thom
  20. Until somebody adds a XFD media type, you may have to engineer something. The XFD file format is header-less, it just has the sectors dumped (with the first three being 128 bytes, the rest being either 128 or 256 bytes in length) The disk type is determined by the file size. and once the disk type is determined, a header can be pre-pended to the disk image, e.g. for 90K disks: 96 02 80 16 80 00 00 00 00 00 00 00 00 00 00 00 96 02 = checksum for NICKATARI 80 16 = 5,760 paragraphs in size (92160 * 128) 80 = sector size 128 bytes 00 = high byte of disk size (used for very large disks) 00 00 = 16-bit CRC (pretty much ignored by everybody) 00 = unused 00 = bit 10 is used by APE to denote read only disks, otherwise unused. 00 00 00 00 00 00 = unused For those who want to implement a media type in fujinet, you can copy diskTypeAtr and base your code on that: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/media/atari/diskTypeAtr.cpp and add the new media type to disktype.cpp: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/media/atari/diskType.cpp
  21. #ColecoAdam #Z88DK Need some help on the SmartKeys proportional font output routines that are in smartkeyslib. https://github.com/tschak909/smartkeyslib Currently, the code in smartkeys_putc() https://github.com/tschak909/smartkeyslib/blob/main/src/smartkeys_putc.c will literally plot a single dot for each bit shifted in a row. This is wildly inefficient. There is code in SmartWriter for the font output, that is much faster, and could possibly be adapted. https://adamarchive.org/archive/Adam/Technical/ADAM SmartWriter ROM ASM.zip (see the SK_ symbols) Can anyone help to pitch in? Could really use the help, as I am stretched thin, trying to get FujiNet for Adam to 1.0.
  22. #FujiNet #ColecoAdam #CPM I can work with somebody to build bindings for their favorite language, e.g. Turbo PASCAL. Anyone want to jump in? All FujiNet networking functions can be done with writes to the correct AdamNet DCB, we just need a few bits of info, here's the data structure for a DCB in 😄 typedef struct _dcb { unsigned char status; // 1 void *buf; // 2 unsigned short len; // 2 unsigned long block; // 4 unsigned char unit; // 1 unsigned char reserved0; // 1 unsigned char reserved1; // 1 unsigned char reserved2; // 1 unsigned char reserved3; // 1 unsigned char reserved4; // 1 unsigned char reserved5; // 1 unsigned char dev; // 1 unsigned short max_len; // 2 unsigned char type; // 1 unsigned char dev_status; // 1 } DCB; // 21 bytes total And these exist contiguously immediately after the 4 bytes that comprise the PCB. One DCB for each device found on the AdamNet. Notable entries: * status - This does double duty, as both the status and command byte. You write the command, the Adam does the operation, and writes back a status sometime later. * buf - 16 bit memory address in Z80 space for the target operation * len - Length of I/O operation relative to the buffer. * block - Used by block devices to denote the desired 32-bit block address. * unit - logical unit number specified. * dev - The Adamnet node number for this device. (1 = keyboard, 2 = printer, etc.) * max_len - The maximum size of payload allowed for this device * type - Device type, 0 = character, 1 = block * dev_status - The 8-bit status byte returned in the last byte of a status packet. So all we have to do for a typical program is to: * Define a data structure that nicely maps a DCB * Find the DCB we want in memory by comparing against the dev entry until we find it. * Write to that section of memory any time we want something to happen for FujiNet * Periodically poll status to see when that operation is considered complete by the 6801. For MBASIC, I was able to do this with the following code: 64000 REM FUJINET ROUTINES 64010 REM ---------------- 64011 REM DCB FUNCS 64012 REM ---------------- 64020 DCBLEN=21:DCBEGIN=&HFEC4:DCBNUM=&HFEC3 64021 NET$=STRING$(255,0) 64022 STAT=1:WRI=3:REA=4 64030 DEF FN DCB(X)=X*DCBLEN+DCBEGIN 64040 DEF FN DCBSTATUS(X)=PEEK(FNDCB(X)) 64050 DEF FN DCBCMD(X)=FNDCB(X) 64060 DEF FN DCBBUFL(X)=FNDCB(X)+1 64061 DEF FN DCBBUFH(X)=FNDCB(X)+2 64070 DEF FN DCBDEVSTATUS(X)=PEEK(FNDCB(X)+20) 64080 DEF FN DCBDEV(X)=PEEK(FNDCB(X)+16) 64081 DEF FN DCBLENL(X)=FNDCB(X)+3 64082 DEF FN DCBLENH(X)=FNDCB(X)+4 64090 DEF FN DCBNUM(X)=PEEK(DCBNUM) The above sets up a nice little data structure that can easily traverse through the DCBs, finding them relative to the PCB at $FEC0. You can then find the correct DCB with the following code: 64093 REM -------- 64100 REM FIND DCB 64101 REM -------- 64110 FOR X=0 TO FNDCBNUM(0)-1 64120 IF FNDCBDEV(X)=9 THEN NET=X:RETURN 64130 NEXT X 64140 RETURN Where we look for the DCB that matches device ID 9, or the first network device, and if found, set NET to it. We can then send network operations with the following common code: 64150 REM -------------------- 64200 REM DO FUJINET OPERATION 64210 REM -------------------- 64220 GOSUB 64100:REM FIND DCB 64230 POKE FNDCBBUFL(NET),PEEK(VARPTR(NET$)+1) 64240 POKE FNDCBBUFH(NET),PEEK(VARPTR(NET$)+2) 64250 POKE FNDCBLENL(NET),PEEK(VARPTR(NET$)) 64260 POKE FNDCBLENH(NET),0 64270 POKE FNDCBCMD(NET),CMD 64280 IF FNDCBSTATUS(NET)<&H80 THEN GOTO 64280 64290 RETURN Because of the functions defined above, finding the correct addresses in memory is very easy, and we simply POKE the operation we want to do, taking special care to make sure that the very last byte written is the command (into the status/cmd byte!). After this, it's a simple matter of checking the status byte for the last bit set, to indicate that the command has completed. After this, doing FujiNet commands is as simple as: NET$="O"+CHR$(12)+CHR$(0)+"N:TCP://192.168.1.10:8080/":CMD=WRI:GOSUB 64200:REM OPEN NET$="WTHIS STRING GETS WRITTEN OUT."+CHR$(13):CMD=WRI:GOSUB 64200 REM WRITE NET$="C":CMD=WRI:GOSUB 64200:REM CLOSE NET$=STRING$(255,0):CMD=REA:GOSUB 64200:REM READ ANYTHING WAITING INTO NET$ and so on. Does this make sense? -Thom
  23. Since the firmware is in development, and there isn't a version of the FujiNet with a smartport, we have attached one of @mozzwald's SIO break-out boxes, that are commonly used for tapping with a logic analyzer. This is my setup here on a //c+ The firmware is in the 'iwm' branch of fujinet-platformio, and spsd.cpp contains the pin-out information: -Thom
×
×
  • Create New...