Jump to content

retroclouds

+AtariAge Subscriber
  • Content Count

    1,753
  • Joined

  • Last visited

  • Days Won

    1

retroclouds last won the day on November 16 2015

retroclouds had the most liked content!

Community Reputation

632 Excellent

About retroclouds

  • Rank
    Stargunner
  • Birthday 01/05/1973

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

19,947 profile views
  1. 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
  2. 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.
  3. 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?
  4. 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)
  5. 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.
  6. 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)
  7. I wonder if there is a Geneve in the Pbox, I mean the manual is there.
  8. 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?
  9. Thanks. I want to give this a try. Basically want to see what I can accomplish with the MAME debugger.
  10. 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
  11. 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 *
  12. That's something I would like to try. I've successfully compiled MAME on my Ubuntu desktop machine and it works so far. The thing is that I don't have any ROMs at this time. Well the ones I do have do not work, although I configure MAME to use my directories it keeps saying the selected software is missing files. Probably will have to invest more time in getting MAME properly configured
  13. Yes, I'll prepare and send you the test, probably tomorrow. One thing to note is, that if I set "Break on Disk Corrupt" the execution halts with the following Debug warning: Warning: DSRLNK functions should store the DSR address of the device name entry at >83D2! (Got >4019) So classic99 did catch that something is fishy. It seems that the DSRLNK is saving an invalid address out of the DSR header to >83D2 That could explain that the card is turned on, but the actual "bl *R9" branches to an invalid location in the Disk Controller ROM and then goes bananas. What steps would I need to do to patch the real TI disk controller ROM in classic99? I made a custom cart with the disk controller ROM at >4000, but the TI-99/4a title screen does not appear and I see a lot of debug messages. According to the debug messages it seems it is having issues with the DSR powerup routine.
  14. That's a crazy setup you have there. But I guess that's what one needs to be able to do those great videos you make. I really enjoy them! Thank you for that 😀
  15. Thank you for all the valuable input. I knew this was the right place to ask. 😉 Please bare with me while I go through the details.
×
×
  • Create New...