Stuart

Does anyone have a PAL programmer? Most USB programmers will do GALs, but there isn't a GAL equivalent for the PAL12L6. Or someone fancy knocking up a little PAL12L6--> GAL16V8 adaptor board? *** Correction - looks like a GAL16V8 can directly replace a PAL 12L6 ***

Another error or two on PCB layout, and I can't edit my earlier post ;-/ -- 74LS123 towards top right of board. No connection to pin 16 (Vcc). Should probably connect to the decoupling cap just above it. -- 74LS11 towards bottom left of board. No connections to pins 1, 3 ,5 (a wiring error around here I think - the 2Y output on pin 6 is shown as connected to pin 2, which is connected to A13 from the PEB). (Also pins 8, 9, 10, 11 but this gate is possibly unused.)

Equations for PAL U12 attached, as far as I can work out. The address decoding looks convincing. Doug, are you able to program a GAL (when you have time) and run it through your reader to see if you get the same data? I can create a JEDEC file if needed.

Doug, spotted two errors on the lovely PCB layout: (1) The trace to PAL U12 pin 3 isn't connected to anything - I assume it needs a green trace going vertically down to A1 on the PEB edge connector. (2) I can't see how the ground trace running round the left / top / top-right of the board is connected to the ground trace at the bottom-right of the board. Is there a ground trace missing round the corner just below the floppy connector? Or maybe to the GND pins at the left end of the PEB connector?

Doug, what are your thoughts behind your design for the PAL 'reader'? Going to try reading it in something like an EPROM programmer? I'm a little confused over what seems like rather complicated connections ...

Cheers Greg. I've got a Matt 32K sidecar, so no problems there. Just checked by Rasp Pi and its actually a Pi 2 Model B. Do I definitately need a Pi 3? Or will it work with a Pi 2, but not 'guaranteed'? Stuart

Well I have got as far as just ordering myself a TIPI so I don't have to encumber other poor souls to test iterations of the code for me ...

Great work Doug! Have you done a schematic as well as the board layout?

Ricky, sent you a PM.

Is there a way to convert data saved on a tape to digital data? Specifically, getting the data from a tape image normally loaded using the MiniMem EasyBug L command. Part of the problem is not knowing where in memory that data is being loaded ...

He means the Tomy Tutor doesn't use the 9901 ...

>> Perhaps add some SAMS support? << But I think that that at the moment would reduce the possible user base even more. >> Are you working on a TIPI version? I know Beery got it working with MXT without too much pain. << Yes, I've done a proof of concept for calling the TIPI services correctly. Part way through doing a TIPI version of the browser but needed Omega's help to test it (I don't have a TIPI, or even a TI-99 set up at the moment), and he's been pretty busy. >> What IS it written in? Assembly? << Yes, it's all assembly.

Hello! I've pondered adding file download capability to the browser because it has been mentioned before. There are a number of issues, as I see them: (1) Adding file download capability makes the program bigger, thus decreasing the size of web page that the program can download and render (the web page has to be held in memory). At the moment the program can just about download the chess web page; adding any extra capability and it won't be able to handle that. It might be possible to use some sort of program overlay to load the code to download a file then reload the browser code, but that gets difficult when people want the program in different types of cartridge etc. ... (2) If the requirement is just to handle downloads from an FTP site then that could probably be handled by a completely separate program. If just 'browsing' an FTP site then that could be handled using a video text mode, rather than rendering pages using a video graphics mode (so a smaller, faster program). (3) I'm not sure how the program would handle all the different file types (EA3, EA5, BASIC, Ext BASIC, relative and sequential files, ...). It might be that a TIFILES header or similar provides all the information needed to recognise the file type. If a TI file needed some sort of 'processing' to put it into a particular format suitable for upload then download, that's an impediment to 'just anyone' uploading files. Which brings me on to ... (4) How many people would actually use it anyway? After the initial "that's cool", it might well just fade into non-use. So a lot of work for something used by people you could count on one hand. Unless done for one's own personal enjoyment of course. (5) Is file download functionality something that the TIPI devs might want to add to the TIPI itself? A new TIPI call with URL and storage device name parameters, and the TIPI handles it all? Stuart

>> Correct! That being said, if you're using AORG in relocatable code, the question arises "Why not just make it EA5 then?" << I do go as far as using compressed EA3 sometimes. >> Relocatable code was the future, of course, with modern computers everything is relocatable anywhere. It's an interesting design that I haven't seen on other 8-bit computers at the time, having both fixed and relocatable code options in assembly. Possibly a reflection of TI's adaptation of mainframe style design? The fact the assembler has support for segments which to my knowledge no one has ever used is a sign of that as well. << The TI-99 assembler is a direct descendent of the assemblers used on their Model 990 minicomputers. So it is pretty full featured.

Adding a note that with EA3 you can if you wish use the AORG directive in your code so that it loads at a specific address, rather than your code being relocateable and letting the EA3 loader decide where to load it.

No, your line 30 is wrong. The PET toggles a bit that switches on an air compressor that blows through a kazoo that is next to a microphone that feed an audio tone into the TI.

If you believe wikipedia then "Today manufacturers produce the 1N4148 and sell it as either part number."

Yes they could. If you're using the built-in keyboard scanning routine, I suspect that that will set them as outputs when doing a keyboard scan anyway - but never tried that so would need testing.

Fabrice - send me a PM with your postal address and I'll get them off to you. If postage is any more than a couple of pounds then I'll let you know. Stuart

I've been given 2 off V9938's. Look unused, *no* guarantee that they work. Any use to anyone? Free apart from the cost of postage from me in the UK to you. Stuart.

If you're talking about the 9901, then you can do a software reset of the 9901 to reset the I/O ports you've used for output back to inputs again. A bit clunky but it does work (depending on what *exactly* you're trying to do) - I used the technique to implement an IDE interface on a 9901 on one of my boards.

You can use the joystick port for both input and output - http://www.stuartconner.me.uk/ti/ti.htm#i2c_interfacemight give you some useful information. Although if you're interfacing with a Commodore PET, you really ought to find an IEEE card for your PEB and interface over the IEEE ports - that would be a great project.

On the top of the plastic body there are two circular areas. On all the genuine 9900's I've seen, the body has a textured finish, apart from these two circular areas which are smooth. But on all the relabelled 9900's those two circular areas are also textured. So I could imagine them getting genuine 9900's, planing a very thin slice off the top of the package to remove marks and scratches, then somehow texturing the whole surface, then applying a new label (which is always very white and sharp compared to the genuine labels). An awful lot of effort, so what are they gaining over just selling the genuine chips as NOS? Especially as any 'in the know' can recognise the relabelled versions and is cautious of them.

I get the occasional TMS99xx IC from the eBay seller "polida2008" and they have (so far) been genuine, perhaps with the IC pins re-tinned. He's got some 9900's on there now: https://www.ebay.com/itm/1PCS-Microprocessor-IC-TI-DIP-64-TMS9900NL-TMS9900/273089911545. If you got a couple then it won't break the bank if they are no good. I've got some of the 'remanufactured' 9900's from China and so far they've all worked, but I don't know about their longevity.

Haven't looked at the subroutines very closely, but on the third of your screenshots, I think you need to move the STOP line from the end of your listing to before the VSBW label. After the block of START code the program continues straight into the VSBW code and the B *R11 at the end of that is sending the program off to somewhere unintended in memory.