It even has a keyboard!
To make the experience fit your profile, pick a username and tell us what interests you.
did a quick test comparing the linking of the 83+ and 86 via blacklink cable through a usb converter... The results are nearly identical.
I did quite a bit of hackery to the tilp2 linking library a while back. One change was to verify the writes before moving to the next step. The result is interesting... in that the original ser_io_wr() write function pretty much directly calls the IOCTL to write the serial port's handhaking outputs. Now, reading them back uses the same ioctl as reading the serial port's handshaking /inputs/, which is used by ser_io_rd(). So, the question, I guess, is whether those /outputs/ are actually read-back via extra circuitry, or whether it merely reads back the value stored in the latches that eventually drive those pins.
This comes up because: it almost always takes three write-verify attempts before verifying properly. This could be due to USB, as discussed in an earlier log; I /think/ when one requests e.g. a port-read through USB, it responds /immediately/ with whatever was read from the port /already/.
So, writing the output registers, then immediately reading them back... well, the read-back may result in what was on the latches /previously/, if the internal polling isn't particularly fast. But, Three attempts? Now I begin to wonder if it's actually reading back the values on the pins themselves! Weird, I'm pretty sure those signals are output-only...
Anyhow, the result, here, is that my write-verify technique results in many reads of all the handshaking inputs and outputs, but only pays attention to the outputs. Which could explain why some intermediate states go undetected, e.g. the moment between when the computer sends a change but before when the calculator responds to the change. From the way it looks, now, the calculator seems to respond instantaneously...
The problem with looking for that intermediate step doesn't present itself except between the end of one bit transmission and the beginning of the next. As I explained in a previous log, in some cases it's impossible, without seeing that intermediate state, to know whether the calculator has responded to the end-of-bit with the beginning of the next bit, or if it's taking a long time to respond to the end-of-bit. Thus the somewhat arbitrary (and surely far too long, in most cases) "delay" between bits.
So, my write-verifty technique may be catching then discarding that intermediate state, but I think the fact is it could just as easily be missed by a slow computer (or USB bottleneck) which can't perform a read in time. So, actually, it's kinda amazing it works at all, and part of that has to do with the fact that the only thing in the original code that looks for those intermediate states is a while-loop that usually just falls through immediately, because the intermediate-state is too fast to be detected by a read after a write.
But *IF* we could see that state, then the delays could be removed, and the communication would occur at the fastest rate possible, handshaking all the way.
So, I'm still pondering... If I do anything in this regard, I think I'd like to keep it compatible. I mean, sure, I could add an edge-detect flip-flop, and feed its output to an extra unused serial handshaking input (Ring Indicator)... but then I might as well be designing a new link cable entirely, no?
Similarly: TIOCMWAIT may be an option, but apparently few USB-Serial converters' drivers implement it. In fact, the PL2303 linux driver seems to have most of the groundwork which is only useful if it's there, but yet it's not implemented, and I'm pretty sure I recall reading in an email discussion regarding implementing it that basically "don't bother, since few USB-Serial drivers do." Which leads me to wonder if either A) someone wrote that groundwork unaware that the chip can't support it, or B) the chip can, but no one uses it since most folk have accepted the limitations of other chips.
And, regardless, then it becomes a question of end-goals......Read more »
Found a TI-83 Plus at Goodwill, just now... I don't really plan to "switch teams," at this point, though I haven't really gotten too fond of the 86's menu system despite ogling the 85's in my 82 days... I find it more flashy than functional. But, I'm pretty familiar, now, with the 86's innards and potential for hackery, and yah know that's my jam.
...Though, the 83+ has FLASH... Hrm...
The main idea, at this point, is another point of reference for the linking issues in the last logs. May be similarly useful in other ways.
It's been on the shelf there for well over a month, I guess they're no longer in as much use in schools around here these days. So, I don't feel like I'm keeping it out of the hands of a kiddo who needs a deal. And, it may also mean that these things, abundant as they once were, will become available in large quantities to "hackers" like me to do interesting things with... I dig finding uses for what others deem no longer useful... Keeping them outta the landfills....
Z80's being still in use in products even these days, it's still got decent potential for low level Z80 learning...
And from what I've gathered it should be possible to throw a tiny bit of logic at the memory-bus to make for memory-mapped I/O, even throw a UART at it...
So, now the thing could be used like a bulky microcontroller of sorts. Which just happens to have a screen and keyboard... I dunno, I kinda visualize it atop a robot kinda like HERO, as the brains... Who knows. Maybe a bit ridiculous these days, but... Seemingly doable, anyhow.
I also envisioned a bunch of teeny toggle-switches (No, DIP switches do NOT sound fun to toggle!) and LEDs at the space at the bottom of the keyboard, get some hard-core coding goin' on, kinda like this guy:
This makes working with the 83+ seem a lot more appealing :/
Lots of discussion regarding "FLASH applications" and "archive memory" which both sound like they're stored in flash memory.... which, again, would be quite nice to use while trying to code /on/ the device... seeing as how my last assembly program attempt wiped the RAM of the 86, because I forgot to add "ret" at the end.... whoops.
OTOH, the challenge of adding FLASH to the 86 is one that has its appeal. Physically/electrically it looks to be relatively simple enough... a few bodge wires, maybe, for an extra address bit. Or maybe a tiny bit of logic. But, software-wise, we're talking a bit of a challenge, since where would we store the actual code to actually access what's in the extra memory-space that's not accessible by the ROM-based OS, but in a RAM-based application which could get wiped...!
Thoughts are: there seems to be one ROM page which is empty... so maybe the boot-rom could be modified/appended slightly... (but, accessing /that/? Maybe only via a tiny hand-entered "hex" application? Which could almost as simply just go straight to one of the /other/ addresses in FLASH not originally dedicated to the OS... and, then, the flash chip could actually be mostly piggy-backed on the ROM, so wouldn't have to copy its contents and desolder...) but, still, that means the only way to access it, after a wipe, is with a special program which would have to be copied-over either from a computer or hand-entered... anyhow, and then, of course, applications to move things around between executable memory-ranges, etc... Not a small endeavor, but doable I think.
Also, those notes regarding the 83+ make it sound like maybe TI might've gone out of its way to deny access to certain/extra memory addresses... which could put a huge damper on adding mem-mapped I/O. So, still not switching teams...
at a multi-day loss for any idea how to proceed, I wrote several draft log entries touching on the concepts I discovered in the last post...
Some of those are much more detailed, including some schematics and explanations of the bit-level link protocol... but, that stuff's on the web and surely better-explained (and understood)...
But one result of the final attempt, which got posted in that last log, was a moment of curiosity about how the link cable is actually implemented, electronically.
So, immediately after finishing that log entry, I ripped open the link cable...
Above: This is laid-out roughly as on the PCB itself.
Below: These are the sub-circuits, as I understand/guess. More detail follows.
The upper left circuit implements one of two identical circuits in the link to the calculator. It is actually quite similar electrically, at the link, to the circuits shown on the web of the calculator's internals...
The LM339 quad comparator has an Open-Collector output, thus, the wire (marked with an X which is really two point-to-point arrows, indicating it's bidirectional) is either pulled up by the resistor, or tied down through the transistor in the 339's output. (Both sides of that wire work the same, so it could be pulled-down at the other end).
The power is interesting... they draw a positive voltage from one or both of the RS-232 handshaking outputs, which ALSO are used for data output. In most cases there will never be reason to send 0x00, one of the bits is usually high. But, this circuit wouldn't handle outputting 0x00 for very long (as the capacitor drains), EXCEPT that if the outputs are both low, the positive rail is really only necessary to power the LM339, which has a wide voltage range... So, usually, it might be running from up to 15V, it could be running from 3V as that capacitor discharges.
Pretty much all the internal voltages seem to be derived from zener regulators. (I haven't confirmed they're zeners, but it makes sense based on their polarity).
There's also the matter of the diodes at the comparator inputs... these may be zeners to assure the input to the comparator doesn't exceed V+, which could happen as the capacitor recharges, or they may just be regular diodes, so -3 to -15V, indicating a '0' will be dropped to more like -0.6V, so as not to drive the input too far out of the comparator's input range. Regardless of whether they're zeners, they do that. So, it could be an interesting double-duty depending on the input level.
Now, there's one other thing... which I'm kinda surprised they got away with. Driving the RS-232 handshaking /inputs/ is done with the comparator output (when low) or a pull-up resistor (when high). But that means "low" is close to 0V... and the RS-232 spec says low should be -3 to -15V, and that anything between -3 to +3V should be considered invalid!
So, I'm aware that folk get away with this in "hacks" connecting MCUs almost directly (without dedicated level-shifters or line-drivers, or even a transistor) to their computers' serial ports... but to think it reliable-enough to put into a product makes me wonder... That's /probably/ part of the reason they say it's "For Windows [Computers Only]" from back in the day when that meant an x86 with long-standardized "hacks" that weren't within official specs...
PCs of the ~386-pentium era were based on many such hacks becoming standardized, e.g. the original floppy controller chip could only handle one bit rate, so when they came out with 1.2MB 5.25in floppies, they added a small circuit to change the clock source depending on whether you put a 1.2MB floppy, or a 360KB floppy in the drive... but /kept/ the same floppy-controller chip. Later floppy controller chips just embedded that "hack" within the silicon, keeping compatibility with that hack, rather than redesigning with a new strategy entirely. Similarly, the original parallel port was output-only on its data pins... but making it bi-directional...Read more »
so, I thought maybe I could speed up the link connection, and it seemed clear how...
Turns out the ti "black link" connection library that comes with tilp2 is a little awkwardly-written... It essentially swaps the two output circuits. There are two signal wires going to the calculator, red and white, and both are bidirectional. Reading each wire is accomplished from two RS-232 handshaking input lines, writing each wire is accomplished through two additional RS-232 handshaking output lines. This isn't dissimilar from the way it's allegedly done inside the calculator... One 8bit port is used for linking. Two bits are used for reading and two other bits are used for writing. In this case, reading occurs on bits 4 and 5 (0x30), and writing occurs on bits 0 and 1 (0x03).
There are MANY low-level code examples for linking via assembly from a calculator, and it appears tilp2's library is built on those examples. However, there is a difference in the two systems. On a calculator, a wire is tied low by writing a 1 to the appropriate bit. The Black link cable, however, doesn't invert it; writing 0 (not 1) ties the wire low.
So, on a calculator, writing, say, 0x01 will be read-back as 0x20. (0b01, both bits inverted gives 0b10... Reading occurs at the upper nibble, 0b10,0000.) Now, on a calculator, writing 0x03 results in both bits being low... Reading back would give 0x00. With the black link cable, however, writing 0x03 is read-back as 0x30. So, then, you might think writing 0x01 on the black link cable, since it's not inverting its outputs, would be read-back as 0x10, right? But, no, that's where it gets confusing, they swapped the output bits in the connection library code. Writing 0x01 (0b01) outputs 0x02 (0b10), and since the read-back wires are not swapped, it will be read-back as 0x20... Just like on a calculator. BUT, this only works when writing one bit high and one bit low. Again, writing 0x03 gives 0x30, and 0x00 gives 0x00, NOT 0x00 and 0x30, respectively, as on a calculator.
It's a clever workaround, swapping the two write-bits, because the code that handles 0x00, 0x30, and 0x03 are, frankly, trivial in comparison to the code that handles 0x01, 0x02, 0x10, and 0x20. Thus, that code could essentially be copy-pasted from one of the many known-functional examples written to be run on a calculator. Then, just swap-out 0x03 or 0x30 with 0x00, and vice-versa, in the few other cases.
BUT: it makes reading the code quite difficult, and comments frankly don't exist.
I set up an experiment which showed that bit transmissions can occur without any of the inherent handshaking built into the protocol... An entire bit transmitted without any calculator or other receiving device connected to even respond. It seemed the "handshaking" was a result of the bit-swap, the computer sees its own message /as/ the handshake, and thus transmits the entire bit as fast as it can regardless of whether the calculator is fast enough (or even connected) to receive it.
Now, the fact is, the calculator is probably far faster at handling the bit-transitions, via interrupts, than the black link cable and reading/writing RS-232 handshake wires... So, the above probably doesn't affect the transmission of the proper bit value.
Then, stupidly, I didn't save that experiment, except as a screenshot... So, when I finally understood the bit-swap, I went back to the original code... And... It seems it should be properly-implemented... And now I can no longer wrap my head around how that experiment could've worked, unless I messed something up. So... Now, back to the presumption handshaking is actually functioning appropriately... And... Now my ideas about how to speed up communication have been thwarted.
Thing is, I saw the experiment work (or not work, as the case may be), and improper handshaking is pretty much the only reason I can think of to cause communication to be so slow in the first place... The"delay" between each bit transmission...Read more »
there are two files I've been referencing for information about the TI-86's ports... both from ticalc.org (todo: link em)
One covers "all" ports, 0-7. The other goes into some detail about port 4. (Was there a third?)
I was looking to try to find how the absolute addressing is handled (does it involve a port-write of A23-16?) and came across "86inc" which attempts to combine numerous include files into one... Under the Ports section there's a Port 11(?) "iall" "interrupts on, lcd on"... (actuall, after MUCH searching, I think that may actually be a value to load into port3?)
Well, the rabbit hole went so far as finding port 11 in the emulator 'tilem' source code. Which is used on the TI-83 and others to configure the LCD controller, and some weirdness that led me to believe the same LCD controller might be embedded into the CPU in the 86... and... I was pretty durn convinced for quite some time, but now I'm not.... as of just seconds ago while writing this. Heh.
That said, I suppose looking into an emulator's sourcecode could tell one a lot about nitty gritty like the memory mapping system hardware... brain (and technology) is /definitely/ not there for that.
well.... this page suggests absolute-addressing does some funky stuff...
The table suggests RAM starts at 0x0c000 (which is where the first page is always "mapped"), but, thereafter continues unbroken (in 24bit addressing mode) all the way through the 128KB to 0x2bfff. NOW, where's that leave the ROM?
From what I've pieced together, the ROM is then sequentially addressable from 0x00000 to 0x00bfff... which means only 48K of the 256K of ROM is accessible via 24-bit "absolute" addressing. That can't be right... can it?
I guess the thought could be that there's no reason for fast bulk copies from ROM... and execution is really only possible through mapping, since the instruction grabber is only capable of 16 address bits... but, still, this seems weird.
The actual logic to do it this way is not much less, maybe even more complicated than, say, treating the first four pages as always remapped from different addresses. E.G. the highest "absolute" address bit (A23) could select RAM if high, ROM if low, then 8MB of ROM could be accessed sequentially and 8MB of RAM, thereafter, starting at absolute address 0x800000. The actual mapping logic to permanently map the first 16KB from 0x800000 to 0xc000 is actually identical. In fact, I'm pretty certain the necessary circuitry would be LESS to do it this way... and it shouldn't mean any different instructions, either.
So, I think I must be missing something...
Earlier I noted that there may in fact be two more chip-select outputs, and that wouldn't fit this scheme. Maybe they're just address lines.
Which brings me to the point in the project where a logic probe and custom test software would be in order... and you know how likely this endeavor is to wipe the memory with a minor slip of the probe... and how much effort it is to reload, in my situation. Now devel on a laptop, even just for each measly pin-test program, seems the way to go. :/ why I gotta be a hardware hacker? It'd be so much easier to write games under these conditions!
So, that's my guess BEFORE absolute-addressing...
And this hokey ugly mess is almost what makes absolute addressing work to match the table... except there has to be an additional bodge to disable mapping for absolute addresses below 0xc000... where's that signal coming from???
A16-23 I could see coming from a Port... but, no, again with the Von Neuman architecture... you can't hold that on the address lines from an out instruction, because the next instruction has to be fetched from the (same) 16bit address bus... so something has to indicate When to use the 24bit address... a signal that isn't typical Z80, no? Unless... hmmm... maybe say all the 24bit instructions are all the same length... e.g. they're all actually 16bit instructions 3bytes long, then a counter external to the Z80 could wait to output the high address byte until three bus-transactions later (and disable it after the fourth)...
I guess I'm intrigued how this could be implemented with a regular z80 processor where internal signals like the A register or some sort of timing-signal are not broken-out, and no special instructions are added... an add-on for other systems... I'd never heard of direct-addressed paged memory... swapping the pages seems time consuming... though, I suppose such is probably implemented in most expanded memory systems.
Ahhh, but look here... These instructions are all one byte long, and could be used to accomplish all the goals...
So, then, the high byte of the address gets loaded to a d-ff on a port via an out command, then it's delayed by one bus transaction before being output to the actual address bus, e.g. via output enable attached to a DFF used as a single bit shift register clocked by, say, the MEMRQ pin. (Which isn't necessarily available at a pin on this chip). So the high byte of the address is available *after* the cpu reads the next op-code (ld reg, (addr) or ld (addr),reg) which...Read more »
This is the alleged TI-85 schematic from https://www.ticalc.org/pub/text/hardware/
I have found some definite differences in my TI-86...
I'll get to those somewhat randomly.
Here's an oddity: BOTH the RAM and ROM have their Output Enables pulled low (active) at all times. The RAM's is handled through some diode-stearing with the backup battery which seems kinda odd in that it seems if the regular batteries are removed, it pulls the /OE low through two shottkey diodes, dropping ~0.7V. Is that "high" with the 3V battery? Or, maybe the ChipSelect is what matters, in that case, duh.
Ok, here's another, then... /ChipEnable seems to be tied directly to the processor... Same with the ROM. So, first, it would seem address-decoding logic splits out one address bit in both forms, active-when-high AND active-when-low, on two separate outputs, as both active-low. This could've easily been done with an inverter. Thus, I'm theorizing that the two otherwise unknown pins right next to them, on the processor, are actually Two More chip-select outputs, for two devices which aren't attached, and, then, Port 5 and 6 which use one bit to select between RAM and ROM (bit6) actually use bits 6 and 7 to select between FOUR different devices. Each up to 256k, with 16k banks.
This is further suggested by some key differences between the TI-85 schematic and what I'm seeing, here. EG on the 85 the processor's "/OE" is tied to the ROM's OE, but on the 86 it's tied to A16 on both the RAM and ROM. A17 to the ROM goes to the next CPU pin, unused on the 85.
So, my guess is there are 18 address lines accessible to the outside, and four chip-selects (which would be two more address bits) so, twenty address bits, total.
Now, that'd be something! Though, there may even be more(?) The memory-mapping ports 5 and 6 would still have two unknown bits, 5 and 4. So it's maybe even possible there are two more address bits, currently unused, before the chip-selects. Haven't quite wrapped my head around whether that still fits within the memory-mapping...
The other oddity about the chip-enable being tied directly, in the case of the RAM, with its OE always active is that the /WR pulse must come *before* the chip enable. Maybe that's normal? OE is overridden by Write?
There was another oddity, which could be beneficial... even though the ROM in here is in fact a high-voltage OTP PROM, its /Program pin is actually connected to /Write-Enable along with the RAM... Looks like maybe they were forward-thinking to add FLASH (or used FLASH during software devel).
On the LCD board is a big TQFP that some might think to be the "LCD Controller"... That's not quite the case. That chip is a T6A40, NOT T6K04: the latter is apparently used in TI-83+ and others, and is an entirely different concept.
Consider it, the one in the TI-83+, a bit like a graphical version of HD44780 Text displays, or a bit like the infamous Nokia LCD, or a parallel-interfaced version of the SPI interfaced displays most folk use these days. That'd be a great one to use with a microcontroller project. They have a framebuffer built-in and you can send commands to turn on or off individual pixels.
THIS LCD, with the T6A40 row driver, (and T6A23 column driver), however, is much more like interfacing a VGA monitor... It has no memory, you have to send all the pixels, in order, all the time, "refreshing" the screen before the pixels fade (or get damaged by DC, in the case of liquid crystals).
So, frankly, all matrix LCDs need this interface: the first row is selected, the columns are loaded sequentially, the next row, all those cols, again, repeat for every row, then start again at the top...
That's apparently what the TI-86's CPU sends to the LCD, very similarly to VGA, with something like hsync to select the next row and vsync to select the first. Thus most LCDs always have essentially two [types of] chips, row drivers and column drivers. Huge LCDs with a lot of pixels have many of these daisychained. They're often on the ribbon cables that go to the glass. The display driver (the CPU, in this case) typically only interfaces with the first row-driver and first column-driver chips.
The display in the TI-83+, however, has the display driver built-in. Think of it a bit like a VGA monitor which has the VGA card built-in, so instead of sending it a VGA signal, you send it VGA /commands/... but it still has that VGAish signal in there somewhere to scan the electron beam across the screen in raster-fashion.
So the TI-86's LCD is refreshed pixel-by-pixel, line-by-line, frame-by-frame... just like a VGA monitor. It's not easy to interface with that... usually requiring a constant stream of pixel data and a framebuffer.
BUT, it has a few great advantages. At least, as far as the sorts of hackery I tend toward. It's possible for the CPU to know and control intimate details about the screen.
For instance, the CPU can know When the screen has fully-refreshed so that new data can be loaded into the framebuffer /between/ drawing two frames. Imagine a movie's playing and you load frames at a different rate than the screen refresh rate... there'd be sometimes where the display would show half of one frame and half of the next.
Similarly, it's my understanding that this is how the 1337 h4x0rz can display grayscale on these screens; do one frame black, the next white.
OR, another (though this isn't really feasible with LCDs since the pixels are slow and don't /activate/ one-by-one, but row-by-row), think of how the NES's "gun" or old "light pens" worked... that isn't possible without knowing exactly which pixel is being /displayed/ and when.
Now, I had an idea for other hackery that could take advantage of the LCD interface to make general-purpose outputs... by extending the resolution sent to the display. This display is 128x64. The TI-86 allegedly has the ability to change the display configuration to 160x64. The display itself would still only display the first 128 pixels on each row, but the data is sent from the framebuffer for all those extra pixels... and because the row drivers and column drivers are physically accessible on the panel, those extra pixels could be used for other purposes, such as turning on a bunch of LEDs, or maybe even producing sound waveforms, or possibly even attaching a sound-chip (SID?) etc.
Now, unfortunately for that goal, the column-driver chip on the LCD panel is designed to handle 160 columns, so it won't "daisychain" the extra pixels out its output port... but...Read more »
Random notes, randomly updating, for now ...
128KB, has one NC pin, pin 9, so 256K in the same form-factor might be a thing, though not seen amongst the list of related parts... it's entirely likely this is JEDEC(?) standardized...
70ns, though 55ns parts exist
Pin 9 doesn't have a visible trace, though neither does pin7, A15, nor several others, which must be under the chip.
1,2,3,4, 7, 9, 10, 11, 12, 13, 14, 15, 16
17, 18, 19, 20, 24, 31
32 = TP1
12, 11, 10 go to far side of board, away from cpu, nearer ROM, A12, A14, and A16. Is that right???
17 traces come out under the chip package, 18 unaccounted-for pins... bah, pin9 might be a pipe-dream.
Interesting note: A16 (on the SRAM, which technically could have its address pins in any order, no?) Seems to go to the ROM... IF it is actually A16 from the CPU, that means that the banked-memory address lines are shared between ROM and RAM. Does that make sense? Hmmm...
Sooner or later a multimeter might help.
Random aside: LCD: 18 Pins from the main board (3 power?) to an LCD board with a big ol' TQFP Toshiba T6A7(?)0 looks to be the row-driver. Appears to have only One pin connecting to the column-driver (e.g. common reset or hsync). 32 pin flex-cable to column-driver, chip-on-flex, many of the pins are tied together... power?
But, that leaves easily 14 signals... seems a lot for a col driver. But wait! It looks like some are connected far-left AND far-right... hmmm....
1, 32 shield?
2,3 -> D4, C18 -> 31, 30
6,7 possibly under board to 27, 26
8? No visible trace
14, 15, 16 -> C21
17-21 -> C21 (other terminal)
8, 9, 10, 11, 12, 13, 22, 23, 24, 25 seem to possibly be signals. 10 bits. Possibly 8-pixel parallel-load...
(Pin 8, no visible trace is at RIGHT side of screen, as viewed, which might be shift-out if a second 128-column-driver were used in a 256-column display.)
Cable to mainboard doesnt seem to have 8 signal traces. And 4pixel parallel load was quite common...
MANY traces to mainboard seem to go into the diodes and transistors at the right... the various voltages for AC?
Also, many of the 10 column-driver traces go straight to vias, which might be connected on the underside.
ROM: AT27C020-15JC 256KB, 150ns
RAM: Yes the 256K version exists, and yes, pin9 is A17. Put in 2000 for the part number's 1000
A16 is connected to both RAM and ROM (!!!)
A17 is not.
Now, technically ROM needn't be wired in order, either, but, There is a chip ID, internally, which could require ordered addresses to reach... ... A0 and A9, all others are low, so they could, still, be in any order to the CPU's.
Why I'm skeptical of the shared A16: because of the memory-banking system and my understanding of z80, having only 16 address bits (A0-A15). Since a register attached to an I/O "port" is responsible for selecting which of two 16KB banks (in ROM or RAM) are shoved into addresses from 16K-32K and 32K-48K... that to me would indicate the highest address bits would be used for selecting the bank within the memory. Further, since allegedly either ROM or RAM can be selected to fill either slot, then the bank selector must have another addressish bit to choose between the two devices' ChipSelect.
16 banks exist in ROM, 8 in RAM, 16x16=256K ROM, 128K RAM...
Four address bits (likely A17-A14) are used to select a ROM bank.
Three address bits to select a RAM bank (A16-A14?)
(Maybe that remaining bit selects between ROM and RAM?)
Actually, the circuit I imagined is getting quite a bit more complex... and if it's as complex as I'm now imagining, then it really wouldn't be much more complex to actually have most of the address bus and chip selects rerouted differently than merely remapping a few address...Read more »
Only, yahknow, numerous hours' trial-and-error and a little bit of progress, and, well, the some 10+ minutes it takes to load ZAC with my cable setup...
Hey, at least I'm laughing... you shoulda seen what I went through at the start of today's endeavor.
<s>This project has probably reached its end for a while.</s>
My stepdad always says "if you get frustrated with a project, call it a day then come back to it the next" ish...
And, frankly, that's never really worked for me, I tend to "fight through" and often work on projects for days on end, sometimes without stopping to eat or sleep.
...yesterday's endeavor got off to a rocky start, the likes of which could've easily led to "time to call it a day" before even starting. I fought through. That, in this case, meant ignoring something that I find EXTREMELY difficult to ignore... but I managed, surprisingly.
... until the mem-clear, which wasn't so frustrating because I lost that work... in fact, it'd be MUCH easier/faster the second time around, since I now have a better idea what I'm doing (I now know some z80 assembler pneumonics!). And I can probably do it better this time, starting fresh... (make libraries of em, dingbat! E.g. PrintBinary()). No, the problem wasn't with the loss, I could even laugh about that... (BTW, be sure not to delete the 'return from call' at the end, or it'll try to execute whatever garbage is in the RAM /after/ your program! That's my guess what happened, anyhow).
No, the problem was that the loss of productivity gave me a moment to recall what I had to ignore to get started in the first place. And THAT got gnarly, quickly. I actually wrote it three different ways, here, but decided it wasn't really shareable.
Anyhow, today I had an idea of a potential explanation for some of the oddities I had to ignore, and some experimenting confirmed them. I guess my stepdad was right this time.
The key factor is: DO NOT try to execute your Assembly code as though it's a (TI-BASIC) program! Otherwise TI-BASIC will reformat everything, including removing leading and excess spaces, and more. This may seem like an obvious "do not" since obviously it won't execute, but it's really quite easy to do /by mistake/...
Here's a really weird one I've not wrapped my head around...
" jp ProgStart" has a leading space, as all asm instructions do, and two spaces after jp... TI-BASIC turns it into "jpProgStart" with all spaces removed. Weirder, if you change ProgStart to ProgStar, it leaves a (one) space after the jp. If you change it to ProgStart1 it removes all spaces again. And, again, as I recall, if you change it to PROGStart. Similarly, the jp can be changed to anything and it does the same, it seems. Apparently "Start" is quite special?
Now, onto the memory-cleared issue...
I could see this being quite a recurring risk... in fact, in my old TI-82 days, as I now recall, I got into the habit of running a full backup of my programs every night, and even more often when I was programming TI-BASIC next to my computer... I've so many shoddily-sorted backups from those days, I have no idea which is the latest, and it'd be quite an effort to try to find out.
The goal, here, was to have a completely self contained devel system... and that it is... until something goes wrong, and that memory gets cleared, or otherwise mangled, which is easy to do in assembly, and even easier when you're working with really low-level stuff like I plan to... like modifying the ports which configure the Interrupt rates or the LCD configuration...
So, regular backups to something truly non-volatile is even more important. And... that stupid factor, too, of that there's no "undo" and most efforts are saved somewhat immediately... being in pseudo-nv-RAM, after all...
So... at what point does it make more sense to devel on a laptop, despite all the difficulties of doing-so in my situation...?
Some of those issues are learnable to...Read more »
Become a member to follow this project and never miss any updates