retroclouds

Would it be possible to generate timed load interrupts via the SDD99? That way preemptive multitasking could be implemented.

Thanks Lee! That is some great information, it is much appreciated! The Functional Spec. is available in the DevRes Thread so should be able to grab it there. Making the catalog available as a pseudo-file is a cool idea must say.

ok, guess I'll take a look at the specification documents or the "The Art of Assembly Language" series.

Is there an example available on how to read the floppy disk catalog in assembly language?

Hi Folks! now that 2019 is almost over, I'm wondering what events are planned in Europe in 2020? Is there a local event in Germany planned?

Frohe Weihnachten! Viele Grüße retroclouds p.s. Vrolijk Kerstfeest voor alle TI-99/4a vrienden in Nederland en België!

Check your VGA ribbon cable and if it's still tightly connected to the F18a. Had the same issue with my F18a (not the distorted picture, but did have the same colour degrading I've seen in your video). At one time I ripped the VGA ribbon cable by accident and had to solder it back in place. The ribbon cable now looks ugly as hell, but works flawlesly. oh, by the way. That is some most excellent work on the SDD99. Looking forward to that. Do you run your debugger on TI side or is it running in the FPGA and is constantly monitoring the bus?

Thanks for pointing that out. So this means the MBI could be in a good state and I should be able to dump the DSR.

On the contrary. The Adamed editor inspires me to keep working on this. I really like what I saw in the youtube video.

ok, so I used my phone to record floppy file reading. What you are seeing is TiVi running on the final grom cartridge and using the F18a in 31 rows, 80 columns mode. I'm loading the XBEADOC file from floppy drive 2. During loading you see the VDP buffer, which is kinda handy as it allows me to track file loading progress for now. Counters on the bottom left line show lines read and kilobytes read from file. I made a quick patch to bail out of the file reading once high memory expansion (>a000->ff..) gets full. After that I start moving around in the file and do some line inserts/deletes. Apparently still have some issue when reaching end of file, but that'll have to wait for another day. It's kinda rewarding seeing this run on the TI-99/4a itself.

ok, so this evening I made some good progress on importing a file into TiVi. Now that pieces are starting to fit together it was real easy to do. Did my first tests with an 8 kb file (speechdocs) and with the XBEADOC file, which is 56 kb if I'm not mistaking. As I do not have SAMS support working yet, I stop loading the file once the 32kb high memory area gets full. For my tests I'm loading the files from a real floppy. Tests with ramdisk, cf7/nanopeb/tipi will have to wait for now. Anyway I'm really pleased with the file browsing / editing speed. Inserting and deleting lines is very fast. I'll try to add a youtube video

Thank you for that. Nice, so the one listed here is the centronics version. I wonder if they wrote an own DSR or if the DSR is ripped out of another device.

Here's a little device I bought on ebay. Got it out of curiosity really. Costed me 40 EUR including shipping in Germany. It's a centronics interface that plugs into the sideport. Basically what interested me most is what DSR is included. Appears to have costed 299 german mark back then. That is according to the "Kaufhof" label that is still on the original box. Probably boils down to 300 EUR nowadays. I scanned the device using my own DSR scan program, but nothing shows up. So either the device is broken or it needs power from an external source (the centronics interface?) Anyone else seen such a device before? At least it's new to me. Centronics would be matrix printer style right?

You could also consider doing many of the asteroids using background graphics. I admit would make things a lot more complicated, but quite sure it would work out real nice.

I've been working on adding file system I/O to the underlying spectra2 libraries and have been doing quite some refactoring in the progress as well. So next steps is to incorporate the updates in TiVi. Actually doing file I/O and the refactoring of spectra2 took a lot more time than I anticipated, but I think it is well worth the effort. Using spectra2 so far I was completely isolated of the surrounding TI-99/4a (except for joysticks and keyboard input, which is also an own implementation). When doing file I/O basically using the peripherals made it necessary to change stuff to be more aligned with the TI-99/4a. The refactoring I did should allow me to combine spectra2 with C a lot more easily, which is something I want to concentrate on next year. What I can definitely tell is that the project is not dead. I'm basically hopping back and forth due to dependencies. My next milestone is to have save/load possibility for large text files in TiVi

Thanks for the replies. Not sure what I'm going to do next. I guess I'm somehow blacklisted at customs. But I don't know why that be the case. I'm a collector and rarely sell stuff. Anyway if I go down the Phoenix road again, I'd try to buy it used in Europe. At least if the price is reasonable/the same. But that won't happen anytime soon/ever I suppose.

I am located in Germany and yesterday I had a rather disappointing issue with german customs and the Phoenix.... This week I was contacted by them that I had to come by to their "service-point" for picking up a parcel that normally is delivered to my home. That ain't the first time that happened. It mostly happens if I order stuff from abroad like US, Canada, Asia. Reason is that european import tax is not visible on the parcel and they can't identify what's in the parcel. So I thought, ok this is business as usual. Go to their service-point, open the package so they can look inside and charge you import tax (which they always do on both product value and shipping costs, go figure). However, this time was different. They instructed me to open the package and they inspected the Phoenix looking for the "CE" Label (Conformité Européenne). Then they told me that the "CE" Label on the Phoenix game console is not valid, because it is just a sticked-on label. To be a valid "CE" Label it must be imprinted in the console case. Basically I had 2 options; either allow them to send the parcel with the Phoenix back to Collectorvision or send the Phoenix to German Telekom so they can do a "CE" validation, which probably would take a year or so, would have costed me thousands of euros and low chance on successful validation. So long story short, they did not allow import of the game console into Germany and as such I was not allowed to take it home. Very frustating finally briefly holding the Phoenix in your hands and then to let it go. Customs is now in the process of sending the parcel back to Collectorvision. I'm counting on Collectorvision to refund the phoenix as Paypal insurance doesn't help here because 180 days warranty period has passed. This is all very disappointing as I preordered the game console in May 2019, So what is to be learned out of this: 1. When shipping to Europe (especially Germany) make sure European import taxes are paid in advance. That increases chance that customs doesn't check package contents. 2. Perhaps Collectorvision needs to check "CE" Conformity of the Phoenix once again, especially regarding positioning of the "CE"-label. Not as a stick-on label but imprinted in the console itself?

I filed an issue on github for this. Thought I might share here in case some runs into. Presume this is not the only instruction, but applies to the class of instructions seto belongs to (haven't checked though)

That is most interesting! Didn't know about Thierry's HyperAMS extension. http://www.unige.ch/medecine/nouspikel/ti99/hams.htm Yes, would be mighty cool having something like that as sidecar. Although would already by very pleased with a SAMS sidecar by itself.

What would it take to map some of the memory in the >4000 area so you could load and "bankswitch" your own DSR in there? Would allow for some quite interesting experiments (e.g. ramdisk lite)

I wonder if there is a Geneve in the Pbox, I mean the manual is there.

I'm using my spectra library that basically clears all of scratchpad and VDP RAM upon program initialisation. That's the reason why I'm interested in building a memory map for scratch pad and VRAM, so I know what memory locations are "reserved" and/or what values are expected. I know I'm learning this the hard way, and takes longer but it does help me a lot better to understand file I/O & DSR architecture. Most of the gaming stuff I programmed on the TI-99/4a in 9900 assembly, runs basically very isolated as barely anything "external" is used. Now with the file I/O it's a different thing, but I guess that's part of the fun. I'm not at my Windows Desktop machine, I think I've seen the Disk buffer header corrupted at >xxxxx debug message before. Quick question; would it be possible to add a buffer with scrollbar to the classic99 debug pane? That way if messages roll off the screen I can still review them by scrolling up?

Thanks. I want to give this a try. Basically want to see what I can accomplish with the MAME debugger.

Attached is a first draft version of my minimal scratchpad memory map for doing file I/O with the standard TI Disk Controller. This attached file was create with LibreOffice Calc, but I guess it can be opened in Microsoft Excel as well. Warning: There are still a few locations missing in the memory range >8370->83FF that I need to clarify and that are not yet in the map! As a workaround for now I basically loaded >8370->83FF with values I dumped while running Editor/Assembler and that gets me a working version on the TI-99/4a. data00008370 data >37D7,>9E80,>00FF,>0000,>0075,>0080,>0000,>151B data00008380 data >6117,>6FE1,>0000,>0000,>0000,>0000,>0000,>0000 data00008390 data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000 data000083a0 data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000 data000083b0 data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000 data000083c0 data >5C2D,>0000,>0000,>0200,>FFFF,>FF00,>0484,>0000 data000083d0 data >0874,>0000,>E000,>05D6,>0070,>83E0,>0074,>2002 data000083e0 data >0000,>0002,>0000,>0000,>0000,>0000,>0000,>0000 data000083f0 data >0000,>0006,>4000,>02BA,>0006,>9800,>0108,>8C02 But some of these values can be removed, so have to do more testing. Memory Map for DSR operations.ods

ok, I was able to resolve the lockup. These were the steps I did (well there were quite a few more, but only the below are relevant to the described issue (I also spend quite a few time chasing the DSR chain due to issues in my DSRLNK version). 1. By activating the TI Disk Controller ROM in classic99 I was able to reproduce the same behaviour I experienced on the TI-99/4a itself. 2. To further diagnose the issue I printed the full TI Disk Controller ROM disassembly on paper 3. Basically the first DSR call I traced was the equivalent of "call files(1)" via DSR subprogram >16 (set #number of files) which already didn't return and stayed in the DSR. 4. One of the first things the subprogram does is "BL @>4724". I copied that part of the DSR below. You see the part where 2 bytes of VDP memory is read and returned to R8, well that didn't work out. 5. The problem was that the VDP address to read from is fetched from scratchpad >8370 and I still had that memory location set to >0000 instead of >37D7. 6. I also had to make sure that VDP range >37D7 up to >37DC contains the words: >00AA,>3FFF, >1100 ... and now it works on the real hardware too. DSR disassembly (as found on Thierry's site): *--------------------------------------- * Preparation subroutine * Sets up the 4 custom subroutines * Gets a few pointers to VDP buffers * >8358: copy of VIB >8366: VDP stack ptr (grows down from drive info) * >8354: PAB >8356: ptr to end-of-buffer *--------------------------------------- A4724 INCT 7 stop scanning upon return A4726 MOV 11,10 save return address STWP 9 get workspace (should be >83E0) AI 9,>FF20 top of scratch/pad mem (>8300) LI 0,A4690 entry to 4 custom routines MOV 0,@>005C(9) put it in >835C MOV 9,0 AI 0,>004E workspace for these four (>834E) MOV 0,@>005A(9) put it in >835A MOV @>0070(9),8 highest free address in VDP mem A4744 INCT 8 point to "end-of-buffer" word BL @A4B76 read 2 bytes from VDP address R8, into R0 MOV 8,2 save current R8 MOV 0,8 get end-of-buffer word MOVB @>FBFE(15),1 get CRU of controller that reserved this mem CB 12,1 same as ours? JNE A4744 no: use end-of-buffer to link to next buffer AI 8,>FEF6 yes: point to volume information block MOV 8,@>0058(9) save it in >8358 AI 8,>FFF6 point to disk drive info (drive #, last tracks) MOV 8,@>0066(9) save in >8366: VDP stack ptr (DECT before writing) BLWP @>005A(9) save R7 (return address) DATA >0100 MOV @>0056(9),7 ptr to PAB: end of DSR name MOV 7,3 save it S @>0054(9),7 beg of DSR name MOV 2,@>0056(9) >8356: ptr to "end-of-buffer" word in VDP mem DEC 7 point to name length byte CLR 2 BLWP @>005A(9) set VDP to read from address in R2 DATA >00E2 MOVB @>FBFE(15),2 get name length byte SWPB 2 make it a word S @>0054(9),2 minus DSR name size: lenght of .parameters AI 7,>FFF7 point to top of PAB MOV 7,@>0054(9) save it in >8354 B *10 *