readme and organization

bkw777 · Jan 3, 2024 · a2fff2f · a2fff2f
1 parent 2a515ee
commit a2fff2f
Show file tree

Hide file tree

Showing 39 changed files with 132 additions and 34 deletions.
diff --git a/README.md b/README.md
@@ -39,16 +39,17 @@ The PCB has footprints for four 32k sram chips (62256 equivalent), for a total o
 To get 256k, a second set of chips are soldered piggyback on top of the first four, each with pin 20 bent out and connected to the pcb separately, and all other pins connected to the chip below.  
 No other parts or changes are needed to upgrade an existing 128k unit to 256k.  
 
-![](REF/NODE_DATAPAC_256K_1.jpg)
-![](REF/NODE_DATAPAC_256K_2.jpg)
-![](REF/NODE_DATAPAC_256K_3.jpg)
-![](REF/NODE_DATAPAC_256K_4.jpg)
+![](ref/NODE_DATAPAC_256K_1.jpg)
+![](ref/NODE_DATAPAC_256K_2.jpg)
+![](ref/NODE_DATAPAC_256K_3.jpg)
+![](ref/NODE_DATAPAC_256K_4.jpg)
 
 # Documentation
 The original manual does not seem to be scanned or archived anywhere.
 
 All we have today is a few bits of info from discussions in the [M100SIG archive](https://github.com/LivingM100SIG/Living_M100SIG) and Paul Globmans software on [club100](http://www.club100.org/library/libpg.html).  
-Some of these are collected [here](software).
+Some of these are collected in [docs](docs).  
+See also the docs for the various bits of [software](software).
 
 A few of those documents say that the device originally shipped with the user manual pre-loaded onto the DATAPAC as a 12k text file, along with at least one BASIC program.  
 If/when the battery died in the device and all data was lost, the Format operation in the option rom would also re-create the text file.  
@@ -132,7 +133,7 @@ STEPS
 
 
 If you wish to keep using a rechargeable battery, then a suitable option is FL3/V80H. That is 3 16x5.8mm NiMH button cells in a flat in-line pack with wire leads. It fits perfectly in the space next to the ribbon cable. It needs to be secured with hot glue or foam mounting tape, and connected with wires run to the original battery location.  
-![](REF/fl3v80h_placement.jpg)
+![](ref/fl3v80h_placement.jpg)
 
 The charging circuit is utterly basic, so do not connect any other type of battery except NiCD or NiMH.  
 You can use any cell form factor and any larger or smaller mAh capacity, but must be 3.6v and only NiCD or NiMH chemistry.
@@ -145,11 +146,11 @@ The device is probably hardware compatible with the Olivetti M-10 and Kyotronic
 The device is not compatible with the NEC PC-8201/PC-8300 at all.
 
 ### Model 200
-The connector on the DATAPAC [does not actually fit in a Model 200](REF/does_not_fit_model_200.jpg) without cutting the opening wider around the bus connector on the 200.
+The connector on the DATAPAC [does not actually fit in a Model 200](ref/does_not_fit_model_200.jpg) without cutting the opening wider around the bus connector on the 200.
 
 The only connector that fits in a 200 without hacking on the 200s case is a [solder-type 2x20 male box header](https://www.digikey.com/en/products/detail/sullins-connector-solutions/SBH11-PBPC-D20-ST-BK/1990068),
  which could be soldered back to back with the [female version](https://www.digikey.com/en/products/detail/sullins-connector-solutions/SFH11-PBPC-D20-ST-BK/1990093),
- to make an [adapter](REF/T200_adapter.jpg) to allow [connecting to a 200](REF/T200_adapter_installed.jpg) without having to damage the 200's case.
+ to make an [adapter](ref/T200_adapter.jpg) to allow [connecting to a 200](ref/T200_adapter_installed.jpg) without having to damage the 200's case.
 
 ### Model 100
 The case says "102/200", but it actually works on Model 100 also. It needs an adapter cable, but the cable is simple. It's just a "wire-to-board" IDC-DIP-40 crimp-on DIP connector and a standard 2x20 female IDC connector, both crimped on to a 40-pin ribbon cable about 8 inches long.  
@@ -378,16 +379,16 @@ The connector fits in a Model 200 without having to modify the 200.
 The diode on RAMRST is copied from a user mod found on a DATAPAC. It appears to be intended to prevent a battery drain on the host computer while the DATAPAC is left connected to the host while the host is turned off.
 
 Installed on a TANDY 102
-![](REF/MiniNDP_on_102.jpg)
+![](ref/MiniNDP_on_102.jpg)
 
 Installed on a TANDY 200
-![](REF/MiniNDP_on_200.jpg)
+![](ref/MiniNDP_on_200.jpg)
 
-![](REF/MiniNDP_and_cover.jpg)
-![](REF/MiniNDP_and_cover.back.jpg)
-![](REF/MiniNDP_and_cover.assembled.jpg)
-![](REF/MiniNDP_bank0.jpg)
-![](REF/MiniNDP_bank1.jpg)
+![](ref/MiniNDP_and_cover.jpg)
+![](ref/MiniNDP_and_cover.back.jpg)
+![](ref/MiniNDP_and_cover.assembled.jpg)
+![](ref/MiniNDP_bank0.jpg)
+![](ref/MiniNDP_bank1.jpg)
 
 The 512k board also still supports 256k and 128k. There is no real reason to do this now but if you wanted to install a 256k (AS6C2008A) 
 or 128k (AS6C1008, IS62C1024, etc) SRAM, omit the U8 part (the 1G79), and solder-blob U8 pads 4 & 5 together. Those two pads are modified to also be a solder-jumper for this purpose.

diff --git a/REF/data-layout.txt b/REF/data-layout.txt
diff --git a/software/DPAC.REV → docs/DPAC.REV b/software/DPAC.REV → docs/DPAC.REV
diff --git a/software/NODBAT.THD → docs/NODBAT.THD b/software/NODBAT.THD → docs/NODBAT.THD
diff --git a/software/NODE.102 → docs/NODE.102 b/software/NODE.102 → docs/NODE.102
diff --git a/software/NODE.REV → docs/NODE.REV b/software/NODE.REV → docs/NODE.REV
diff --git a/software/NODE01.THD → docs/NODE01.THD b/software/NODE01.THD → docs/NODE01.THD
diff --git a/software/NODE02.THD → docs/NODE02.THD b/software/NODE02.THD → docs/NODE02.THD
diff --git a/software/NODEBA.THD → docs/NODEBA.THD b/software/NODEBA.THD → docs/NODEBA.THD
diff --git a/software/NODINF.THD → docs/NODINF.THD b/software/NODINF.THD → docs/NODINF.THD
diff --git a/software/NODMNU.THD → docs/NODMNU.THD b/software/NODMNU.THD → docs/NODMNU.THD
diff --git a/software/NODTIP.001 → docs/NODTIP.001 b/software/NODTIP.001 → docs/NODTIP.001
diff --git a/docs/filesystem.txt b/docs/filesystem.txt
@@ -0,0 +1,83 @@
+
+This is just from my own examination combined with reading the available info, not authoritative.
+2024 Brian K. White
+
+A lot more details of the directory and filesystem structure can probably
+be divined from studying RD.BA and N-DKTR.BA
+
+This only applies to the filesystem created by RAMDSK or the NODE ROM.
+The device may also be used as arbitrary raw data storage by other apps,
+and in that case the data may be anything.
+
+Everywhere I say "block" some of the old docs & programs say "sector". They both refer to the same thing.
+
+The first 2 bytes of block 0 = 0x40 0x04 marks the bank as being formatted with a filesystem.
+
+The first byte of block 0 is susceptible to being corrupted with unwanted
+writes during connect/disconnect/power-on/power-off.
+You should never connect or disconnect the device while the computer is powered on,
+but it can still get corrupted even if you always careful.
+
+RAMDSK will offer to fix it automatically.
+Answer "N" to the "Format?" prompt, then "Y" to the "Fix?" prompt.
+
+You can also fix it manually from BASIC by typing:
+  OUT129,0:OUT131,64:OUT131,4<cr>
+
+For bank 1 this would be
+  OUT133,0:OUT131,64:OUT131,4<cr>
+
+but bank 1 will probably never get corrupted, because the problem is electrical,
+and the latch & counter chips that set the bank, block, & byte address are not connected
+to the battery. When the device is disconnected or the computer is turned off,
+those chips all reset to 0, so the only byte that is ever at risk is always the same
+byte 0 of block 0 of bank 0.
+
+The table defining which blocks are used by files is in block 0.
+
+The file names and file sizes are in the first 10 bytes of the first block of each file.
+
+The block table only says that block N is the first block of a file, but not what that file is.
+You get the filenames and filesizes by reading the first 10 bytes of every "first" block.
+
+From looking at N-DKTR.BA lines 2-18:
+The first 512 bytes of block 0 are 2 bytes per block for 256 blocks.
+Excluding the first pair for block 0,
+for the remaining blocks 1-255, if the first byte is...
+ >127 : block is marked "F" - the first block of a file
+ 32   : block is marked "c" - continuation of a file
+ 0    : block is marked "+" - available un-used block
+ else : block is marked "?" - none of the above, which should never happen
+
+(*maybe* the 2nd byte indicates the next block in the chain if any?)
+
+The first saved file starts in block 2 and then continues in block 1
+
+bank 0
+block 2
+
+First 10 bytes are filename and filesize.
+This is filesystem metadata created by RAMDSK or the NODE ROM, not part of the file itself.
+
+0000-0005 RAM100                 name
+0006-0007 CO                     ext
+0008-0009 7E 05 -> 057E -> 1406  size
+
+The next <size> bytes are the file data.
+If <size> is >1014, then the data continues in some other block.
+(block 1 in this case)
+
+In the case of a .CO file, the .CO file format has a 6-byte header.
+This is part of the .CO file format, nothing to do with DATAPAC or RAMPAC.
+
+0010-0011 76 F0 -> F076 -> 61558 TOP
+0012-0013 78 05 -> 0578 -> 1400  LEN  ( -> 62957 END )
+0014-0015 76 F0 -> F076 -> 61558 EXE
+
+0016-1023 data
+
+Remainder of data is on block 1.
+Yes it starts on block 2 and continues and ends in block 1. I don't know why.
+The remaining data starts right at byte 0 of block 1.
+
+The bytes from the end of a file to the end of it's last block are un-used and un-usable.
diff --git a/REF/D2_RAM_RST_bodge.jpg → ref/D2_RAM_RST_bodge.jpg b/REF/D2_RAM_RST_bodge.jpg → ref/D2_RAM_RST_bodge.jpg
diff --git a/REF/MiniNDP_FDS_slip_cover.jpg → ref/MiniNDP_FDS_slip_cover.jpg b/REF/MiniNDP_FDS_slip_cover.jpg → ref/MiniNDP_FDS_slip_cover.jpg
diff --git a/REF/MiniNDP_and_cover.assembled.jpg → ref/MiniNDP_and_cover.assembled.jpg b/REF/MiniNDP_and_cover.assembled.jpg → ref/MiniNDP_and_cover.assembled.jpg
diff --git a/REF/MiniNDP_and_cover.back.jpg → ref/MiniNDP_and_cover.back.jpg b/REF/MiniNDP_and_cover.back.jpg → ref/MiniNDP_and_cover.back.jpg
diff --git a/REF/MiniNDP_and_cover.jpg → ref/MiniNDP_and_cover.jpg b/REF/MiniNDP_and_cover.jpg → ref/MiniNDP_and_cover.jpg
diff --git a/REF/MiniNDP_bank0.jpg → ref/MiniNDP_bank0.jpg b/REF/MiniNDP_bank0.jpg → ref/MiniNDP_bank0.jpg
diff --git a/REF/MiniNDP_bank1.jpg → ref/MiniNDP_bank1.jpg b/REF/MiniNDP_bank1.jpg → ref/MiniNDP_bank1.jpg
diff --git a/REF/MiniNDP_on_102.jpg → ref/MiniNDP_on_102.jpg b/REF/MiniNDP_on_102.jpg → ref/MiniNDP_on_102.jpg
diff --git a/REF/MiniNDP_on_200.jpg → ref/MiniNDP_on_200.jpg b/REF/MiniNDP_on_200.jpg → ref/MiniNDP_on_200.jpg
diff --git a/REF/NODE_DATAPAC_256K_1.jpg → ref/NODE_DATAPAC_256K_1.jpg b/REF/NODE_DATAPAC_256K_1.jpg → ref/NODE_DATAPAC_256K_1.jpg
diff --git a/REF/NODE_DATAPAC_256K_2.jpg → ref/NODE_DATAPAC_256K_2.jpg b/REF/NODE_DATAPAC_256K_2.jpg → ref/NODE_DATAPAC_256K_2.jpg
diff --git a/REF/NODE_DATAPAC_256K_3.jpg → ref/NODE_DATAPAC_256K_3.jpg b/REF/NODE_DATAPAC_256K_3.jpg → ref/NODE_DATAPAC_256K_3.jpg
diff --git a/REF/NODE_DATAPAC_256K_4.jpg → ref/NODE_DATAPAC_256K_4.jpg b/REF/NODE_DATAPAC_256K_4.jpg → ref/NODE_DATAPAC_256K_4.jpg
diff --git a/REF/T200_adapter.jpg → ref/T200_adapter.jpg b/REF/T200_adapter.jpg → ref/T200_adapter.jpg
diff --git a/REF/T200_adapter_installed.jpg → ref/T200_adapter_installed.jpg b/REF/T200_adapter_installed.jpg → ref/T200_adapter_installed.jpg
diff --git a/REF/bottom.jpg → ref/bottom.jpg b/REF/bottom.jpg → ref/bottom.jpg
diff --git a/REF/datasheets → ref/datasheets b/REF/datasheets → ref/datasheets
diff --git a/REF/does_not_fit_model_200.jpg → ref/does_not_fit_model_200.jpg b/REF/does_not_fit_model_200.jpg → ref/does_not_fit_model_200.jpg
diff --git a/REF/fl3v80h_placement.jpg → ref/fl3v80h_placement.jpg b/REF/fl3v80h_placement.jpg → ref/fl3v80h_placement.jpg
diff --git a/REF/new_battery_placement.jpg → ref/new_battery_placement.jpg b/REF/new_battery_placement.jpg → ref/new_battery_placement.jpg
diff --git a/REF/part_numbers_1.jpg → ref/part_numbers_1.jpg b/REF/part_numbers_1.jpg → ref/part_numbers_1.jpg
diff --git a/REF/part_numbers_2.jpg → ref/part_numbers_2.jpg b/REF/part_numbers_2.jpg → ref/part_numbers_2.jpg
diff --git a/REF/top.jpg → ref/top.jpg b/REF/top.jpg → ref/top.jpg
diff --git a/software/N-DKTR/README.txt b/software/N-DKTR/README.txt
@@ -0,0 +1,28 @@
+2024 Brian K. White
+
+Two notes about N-DKTR
+
+1 - Warning: Do not run N-DKTR at all if the NODE has arbitrary raw data that isn't
+a filesystem made by RAMDSK or the NODE ROM.
+
+It appears to overwrite the first 2 bytes of bank 0 block 0 
+with the filesystem formatted flag bytes, immediately on startup,
+without asking if it's ok or doing any other kind of sanity check,
+without the user invoking any functions or responding to any prompts.
+
+This is fine if the device is supposed to have a filesystem,
+but if the device is supposed to have arbitrary raw data,
+then the first two bytes of data are destroyed.
+
+Since it happens immediately on startup without asking or giving any chance to prevent it,
+the only way to avoid losing data is don't run N-DKTR at all in the first place.
+
+(Or modify N-DKTR to improve that behavior, which should be simple.)
+
+2 - Does not support bank1 or >256k.
+
+It looks like it probably could be added fairly easily.
+
+The interactions with the device appear to all be in plain BASIC
+so it should be easy to modify all the OUT129 to OUTX and add code to
+select X=129 or X=133.
diff --git a/software/NBOOT/NBOOTR.DO b/software/NBOOT/NBOOTR.DO
@@ -1,10 +1,10 @@
 0' RUN CO file from NODE blocks 1-2
 0' bank0 K=129  bank1 K=133
-0' NBOOTR 20240102 Brian K. White
+0' NBOOTR 20240103 Brian K. White
 1 CLEAR32,59000:CLS:K=129:P=131:OUTK,2
 2 FORA=0TO9:F$=F$+CHR$(INP(P)):NEXT
 3 GOSUB7:T=N:GOSUB7:E=T+N-1:GOSUB7:X=N
 4 F$=LEFT$(F$,6):N=T+1007:FORA=TTOE
 5 ?@0,A:POKEA,INP(P):IFA=NTHENOUTK,1
 6 NEXT:CALLX
-7 N=INP(P):N=N+INP(P)*256:RETURN
+7 N=INP(P)+INP(P)*256:RETURN
diff --git a/software/NBOOT/NBOOTS.DO b/software/NBOOT/NBOOTS.DO
@@ -1,11 +1,11 @@
 0' SAVEM CO file from NODE blocks 1-2
-0' bank0 K=129 bank1 K=133
-0' NBOOTS 20231217 Brian K. White
+0' bank0 K=129  bank1 K=133
+0' NBOOTS 20240103 Brian K. White
 1 CLEAR32,59000:CLS:K=129:P=131:OUTK,2
 2 FORA=0TO9:F$=F$+CHR$(INP(P)):NEXT
 3 GOSUB8:T=N:GOSUB8:E=T+N-1:GOSUB8:X=N
 4 F$=LEFT$(F$,6):N=T+1007:FORA=TTOE
 5 ?@0,A:POKEA,INP(P):IFA=NTHENOUTK,1
 6 NEXT:?@0,"Installed "F$:?"Type:"
 7 ?"CLEAR 0,"T":NEW":SAVEMF$,T,E,X:END
-8 N=INP(P):N=N+INP(P)*256:RETURN
+8 N=INP(P)+INP(P)*256:RETURN