kelli217

If this is about getting software onto, and data off of, the X16 from (for example) a PC, without reaching around to the back of the X16 to get at the SD slot and saving wear and tear on the card and the slot... aren't there a bunch of X1541 derivatives out there with IEC on one end and variously parallel, 9-pin serial, or even USB on the other end? This could free up the X16's user port for modem or printer connections.

They have some experience in dynamic instruction set translation. They did it for the transition from 68K to PPC, and again from PPC to Intel. What might be interesting would be to see if there's a significant performance boost by building r38 in xCode as a native Apple Silicon application, and comparing it to the Intel version running in translation.

oops, posted a question without refreshing the thread, saw that it'd been asked & answered

This is not 'advanced' coding I'm going to be showing here. I am only just getting back into things, so I'm working at a 'mediocre amateur' level. Consider this less as a tutorial and more as just sort of thinking out loud. I appreciate the arithmetic workaround for MOD; I've used it in the past. I like the logic-based workaround for MOD of a power of 2; that one hadn't occurred to me. I guess the LOCATE could be worked around too. You could do it in BASIC using the screen editor cursor movement characters — which I'll show with {curly brackets} (a.k.a. braces) in the old Gazette style of notating special characters — and the TAB() function. 100 R=15:C=20:GOSUB 1000 110 PRINT"HELLO WORLD!" 999 END 1000 REM SCREEN POSITION (R)OW AND (C)OL 1010 ?"{HOME}": REM START FROM TOP LEFT OF SCREEN 1020 FOR I=0TOR:IF I THEN PRINT"{DOWN}"; 1030 NEXT I 1040 PRINT TAB(C); 1050 RETURN But as BruceMcF points out, you can call PLOT from the KERNAL routines to either set or get the current cursor position on the screen. However, while documentation says to put your cursor column in the X register and row in the Y register, actual experimentation with r38 shows that it's the opposite. So when using SYS to call it, location 781 ($30D) for X is row and 782 ($30E) for Y is column. You also have to clear the carry bit (bit 0) of the status register (SR), in location 783 ($30F). Using SYS pushes the registers onto the stack, including SR, before loading a new one from those memory locations, and pulls it back off after storing the routine's output in that same memory, so the system state isn't trashed by being relatively clumsy with SR. 100 R=15:C=20:GOSUB 1000 110 PRINT"HELLO WORLD!" 999 END 1000 REM SCREEN POSITION - REQUIRES (R)OW AND (C)OL 1010 POKE 781,R:POKE 782,C:POKE 783,0;:REM 783 = SR 1020 SYS $FFF0 1030 RETURN Besides being faster, and using less BASIC code, you can also find out where the cursor is, by setting the carry bit of SR when you call the PLOT routine. The return values will be in the memory locations. 100 PRINT"AFTER PRINTING THIS, THE CURSOR POSITION IS:":GOSUB 1000 110 PRINT"ROW:";R,"COL";C 999 END 1000 REM GET POSITION - RETURNS (R)OW AND (C)OL 1010 POKE 783,1:SYS $FFF0 1020 R=PEEK(781):C=PEEK(782) 1030 RETURN To me, not having an explicit ELSE keyword just means that there's a little bit of spaghetti coding and reversing the order of the code blocks: 100 IF T=1 THEN 150 110 REM TEST IS FALSE (ELSE) 120 ... 130 ... 140 ... : GOTO 200 150 REM TEST IS TRUE (THEN) 160 ... 170 ... 180 ... 190 ... 200 REM CODE EXECUTION PATHS REJOIN HERE (ENDIF) There's also the inline example for simple code, with no spaghetti, but there are potentially two assignment operations, so it's not particularly efficient: 100 A=16:IF T=1 THEN A=32 Again, the 'test is false' code comes first, and it's only overridden if the test is true. This is of limited utility; it only works if the true and false cases affect the same variables. Otherwise, use the code blocks as in the first example.

As of now, the SAA1099 has been removed from the design in favor of the PSG on the VERA and the Yamaha YM2151.

What about an XA1541 or XS1541 cable, hooked from the IEC port to a PC?

There are routines in the old KERNAL for getting the old jiffy clock... SETTIM and RDTIM. But there's also a TOD clock in the emulated hardware and a couple of Sweet16 routines, clock_set_date_time and clock_get_date_time for accessing it. These are documented in the Programmer's Reference Guide. (The year field supports values up to 2155, and jiffies are not supported, though they are used by the routines.) Messing around with X16 BASIC, it seems that TI and TI$ are no longer tied together; setting TI$ to "000000" no longer sets TI to 0 as well, like it did on the C64. Also, TI can be set directly by the user, since it's no longer affected by setting TI$. That leads me to believe that TI$ now uses the onboard TOD clock while TI uses the software jiffy clock like before. Back to the C64, the big hit you get on TI$ is if you do any IEC or tape I/O. The software clock doesn't usually update at all while the I/O is going on. So you'll take a big hit if you do any of that and then try to run the program again without updating the time. The accuracy problem with the CIA is, I'm guessing, in variations of the frequency of the system oscillator from minor voltage differences and components changing characteristics as they age. But it should continue to keep time through I/O operations, even if it's not the best at accuracy. Line 130 was originally entered with keyword abbreviations, and I did the same thing when retyping it into VICE; that's why it's longer than it should be. Whoops. I appreciate the modification to line 190. Thanks for spotting that. The time setting subroutine used to be something you'd have to run explicitly with 'RUN 1000' and wasn't included in a GOSUB, and I changed that when 'cleaning up' the text version without testing it in the actual version. Whoops again.

If this is handled internally by the keyboard's own logic, then activating NumLock for the embedded numpad will result in numpad keycodes being sent to the X16 — keycodes that are unsupported by the X16's PS/2 keyboard driver. Meaning that those keys (789UIOJKLM,.) would appear to the user to have become non-functional. The standard for the AT and PS/2 keyboard protocol is that the keyboard just sends the keycode to the host, though. Then the host is responsible for what to do with that keycode. Since NumLock on a full-size keyboard is on the numpad, and as previously stated, the X16 doesn't support the numpad keys, then I'm fairly confident that the key won't do anything.

For a couple of years of my time in high school (for those not familiar with US usage, the 4 years right before university), I used my Commodore 64 as an alarm clock. I first got my 64 for Christmas during my second year. I didn't do much with it at first, because I didn't have any sort of storage device. No peripherals of any kind whatsoever, really. I played some games on cartridge, and dabbled in BASIC. But starting in my third year, I'd been digging through the user guide and found out about TI$, and decided to use it to wake me up in the mornings. At first, I just PRINTed TI$ directly to the screen, with no formatting. And every cycle through the main loop, it would check for being equal to a hard-coded alarm time, and GOSUB to a subroutine that would play an upward frequency sweep in triangle wave at maximum volume, and I likewise had the sound on the television monitor cranked up... well, not all the way up, but quite loud. At least halfway through the volume knob's range. As the weeks and months rolled on, I added more formatting features to the output. Eventually it would parse the TI$ 24-hour time into 12-hour AM/PM and suppress the zero in the hours display, so that a TI$ value of "170522" would print out as " 5:05:22 PM". Even though I still didn't have storage (I finally got a 1541 in the middle of fourth year), I was so familiar with the structure of the program that I could type it in again in just a few minutes if the computer lost power. But once I did have storage, I saved my best version. Armed with my new Programmer's Reference Guide, I started working on a new version that would use the 6526 CIA internal time-of-day clock (TOD). I'd learned that any I/O would cause the TI$ clock to lose time, and I'd already noticed that it would drift quite a bit over the course of only a few nights. I still have a lot of bits and pieces of paper around that I've held onto since back in those days, over 30 years ago at this point, and as it turns out one of those bits pf paper was a listing from when I'd finally gotten a printer, only a couple of months before graduating high school, an MPS803, and I'd listed out the contents of the work in progress, probably right before I'd stopped working on it. The point where I'd left it was where I was comparing TOD to TI$, printing them both out, fully formatted, but without the alarm feature yet. (I'd had some ideas about changing that as well, such as making the alarm time user-adjustable instead of hard-coded, adding a snooze function, or a progressively louder alarm.) I wanted to see for myself ho much better TOD was before committing to it... and I still hadn't quite worked out how to check for the alarm-set time. What I had done was a fair amount of cleanup. I added some very simple comments, and had all the line numbers incrementing by 10. This would allow me to stuff in several extra lines to handle however complicated the alarm check might turn out to be. Anyway, I rewrote retyped it from the listing. I made PET-Gazette-style curly-brace replacements for special characters. I've included it here as 'time.asc'. I've also loaded it into VICE. However, the host computer I used does CPU throttling for power savings and heat reduction, so starting a run of the program when the machine was at full speed and then leaving it overnight caused both clocks to run almost 30 minutes slow over an 8-hour period. For best results, then, I would suggest running this on a real machine or, if emulated, on a host machine that doesn't slow down the CPU. time.asc

I have lots of thoughts on the limits of what can be accomplished on this platform. Given such projects as GEOS, and Contiki, and Atari GOS, something really amazing is probably possible.

Somewhere around this house I have a TI-99/4A and the cables to hook it up to a TV, but nothing else. I have three Apple IIgs machines. One of them is mostly set up, with a monitor, ADB keyboard and mouse, a 3.5" drive, and a 5.25" drive. The other two are just the main system boxes and nothing else. I might have another ADB keyboard somewhere. I do have a CFFA3000 card that I intend to install in the machine that's all set up, and a copy of the latest version of GS/OS on a CF card. I have a TRS-80 Model 4P currently in an inaccessible location behind a bunch of other stuff. I haven't used it in well over a decade, probably closer to 2. It was working when I last put it away. I also have the shell and some of the wiring for a Model III, but none of the internal hardware. I have 4 Amigas. One is in a box at work, a 4000 with a 2065 Ethernet card and a CGX/3D card, as well as a 2091 SCSI card. The 2091 is hooked to a CD-ROM drive and the onboard IDE is hooked to a 1GB drive. It has a coin cell holder in it instead of a soldered-on battery, too. The other three at home are a 1000, a 1200, and a 2000. The 1000 has a flaky power switch. I used to have a SCSI adapter box for the side of it, but I was never able to get it to work, even once I found the right drivers, so I disposed of it as broken. The 1200 has an internal 3.5" IDE drive where the internal floppy used to be, so I have an old A1010 floppy drive attached to it. (I also have the HD floppy drive that it came with still around in case I ever put a 2.5" HD in it.) I do have another 880K floppy around, a slimline California Arts CA-880, but it stopped working. I think it's something simple, though, so I've kept it around. The 2000 is a nice machine. It has two 3.5" floppies and a 5.25" high-density floppy... and you know what that last bit means. Yep, it has a Bridgeboard. I no longer remember which one, but I remember being impressed when I found out which one it was, so it might be a 2386SX; the 1.2MB floppy only came with the 2286 and the 2386SX. It also has an RF and color composite card in the video slot. I have a couple of Macs. One is an Intel MacBook with a 32-bit processor, so it can only handle Snow Leopard. I've deleted MacOS and put Ubuntu Studio on it. The other is an Intel iMac that has a 64-bit CPU but is still too old for the latest and greatest. It's running El Capitan, though, and it still supports a lot of modern apps, so I've left it alone to continue running MacOS. I've got four Raspberry Pis here and one that's on loan to someone else. At home I have an example from every generation so far: a 1B — the first form factor, but with 512MB of RAM; a 2B; a 3B+; and a 4B 8GB model. The one on loan is a 3B. Lastly, I have several PCs. In addition to my current ASUS Core 2 Quad main desktop machine, I have a 2-in-1 Lenovo Yoga laptop/tablet, and 8 other desktop systems. One of them has VLB slots on the motherboard, and it actually has a VLB graphics card in it as well as an AWE64 sound card. It's a beige box that I got from a recycler/reseller and it seems to have been built to be a multimedia PC. I got another beige box in the same deal but it's much less interesting. The IBM Personal Computer 300GL is also uninteresting, except that it has a Token Ring network adapter that uses an RJ-45 connector, and has a LightScribe CD-ROM drive. The Gateway2000 P5-120 is truly unremarkable. The Compaq Presario is the first system I owned that ran Linux, and it was the first one that had a DVD-ROM drive. It also has a CD-RW drive and a Zip100 drive. There's a Dell Optiplex mini system buried behind some other stuff that has a boot issue with RAM timing, even though I put the RAM back in it that I had taken out to up the specs on it. There's a Compaq Desqpro 386 that's been through a fire and has a partially melted front panel but otherwise works fine and has a combined 3.5/5.25 floppy drive, and a HardCard. The Tandy 1000HX is one that I've been meaning to upgrade with some of the cards that I've seen offered recently for the odd 'PLUS' expansion bus, though it does already have 640K thanks to a card I was able to find on eBay many years ago. The odd one out is the Sanyo MBC-555 which I didn't include in the list of PCs even though it's an MS-DOS machine with an 8088. It's one of those weird early machines that's only compatible with software that uses proper MS-DOS and BIOS calls, because the underlying hardware isn't the same as a PC. It is such an early machine in the MS-DOS era that its dual single-sided 5.25" floppies only support 160K each instead of the 180K single-sided drives that came later or the 360K double-sided drives that were around soon afterward. It was also clocked at NTSC color burst frequency, 3.58 MHz, rather than the PC's 4.77, and was originally delivered with only 128K of RAM. I don't remember if the one I have has the RAM upgrade card, but it does have the RGB graphics card that had as many as 8 colors available at 640×200 resolution while being sync-compatible with CGA.

That's just fine; limits of color depth balanced against resolution is something we Commodore-oriented retroheads are already used to, considering the VIC-20 and C64 multicolor modes.

Are there perhaps any plans that anyone, whether attached to the project or not, might have that are oriented toward implementing a full 320x240 graphic screen in BASIC instead of either being limited to a 320x200 screen with an unchangeable black bar at the bottom or POKEing the VERA directly? Even better, what about 640x480 mode? And if I'm asking for the moon, why not the sun, too? So much of the functionality in the system already is very similar to Super Expander 64 and BASIC 7.0... what about sprite commands, like SPRDEF and SPRMOV and so on? Maybe a SOUND command that handles simple sound commands to the PSG, and an FMSND command that can control the YM2151?

Weird question: Is the board itself more than two layers, and if so, is it possible that an inner layer has a discontinuity or a misrouted trace? I'm just trying to think of something very basic that would nonetheless be difficult to track down.