Jump to content

speccery

Members
  • Content Count

    544
  • Joined

  • Last visited

Everything posted by speccery

  1. That's pretty interesting @Fredrik Öhrström. I remember buying an issue of Nittinian when I was on a language course in Visby as a kid. So brings back some memories. As I looked at the program listing, it is interesting that you're directly injecting the REF entry by pokeing it to memory. It also reminds me of a couple of things I still find to this day surprising about the old BASICs: Why didn't they have the equivalent of POKE (LOAD) and PEEK for 16-bit values? Among my small collection of retrocomputers I have two Oric Atmos computers, and they had DOKE and DEEK commands for 16-bit values. By the same token it would have been useful to have functions such as LOBYTE(x) and HIBYTE(x) to extract high and low bytes of 16-bit values. Also support for conversion to hexadecimal (and perhaps other radix values) would have been welcome. I find it interesting that so many BASICs of the day suffered from these limitations, despite them being super simple operations compared to the other things they supported. Perhaps everybody was just cloning the minimum set of functionality, instead of thinking about machine code integration.
  2. Worked a bit more on the ET-PEB to add support for disk directory reading. This was one of the major features lacking from the firmware. Now it works, although it does not correctly recognise the types of files. That will simple to implement, but requires opening all of the files and looking for the TIFILES header to determine things like record length, display/internal type etc. Perhaps I will do the detection when mounting a disk, so it would be a one time operation. I was initially not considering that pre-detection option since the small microcontroller doesn't have enough memory to spare to store the directories in RAM for all three disks (requiring 3*128*38 = 15K bytes). But then I realised that I was thinking this all wrong, I can actually use the unused parts of the external memory chip used by the TMS9900 for disk buffers. It's a bit slow and cumbersome to use this memory due to the way my DMA interface works, but in the scale of the speed of the TMS9900 still fast. I've come to notice that development of the firmware is quite slow, since I need to study the documentation to understand how these things are supposed to work. Unix style unstructured files are definitely easier to work with Also debugging the firmware could be a bit faster, I'm going old school with just littering the code with printf statements. One convenience I have is that I can reprogram and the flash memory of the microcontroller without needing to power off the TI or loading test software again - the CPLD keeps the memory interface going nicely even while the microcontroller is in the weeds.
  3. I've continued to work on the ET-PEB firmware revisions. While at this I realised that even though the CPLD is very full (123 macrocells of 144 in use) and a pain to route for the software, I still might be able to cram in a few more features. And so I did, I was able to successfully add a two bit configuration register. The register is accessible by the microcontroller. Bit 0: enables memory to appear in locations 6000..7FFF Bit 1: when set, forces the board to what I call standalone mode. Thus with bit 0 the ET-PEB is able to host 8K ROMs in the cartridge address space. Of course this must not be set if there is cartridge plugged in. This is no replacement for other, better systems, but still it may come in handy to have the ability to be able to load from the SD card or on-board memory a cartridge image. Actually I think I'm not write protecting the memory, so it also gives one 8K RAM in the cartridge space. Inspired by the nice TIPI DSR, it might be handy to have a TI-Basic command to load a given ROM file to the cartridge address space. Bit 1, when set, puts the ET-PEB into a mode where it does not respond to memory read or write commands. So it pretty much disappears from the bus, although it may still handle CRU accesses, but I forget if they are readable or write-only. The primary use case for this mode is to be able to use the RAM chip by the microcontroller when the board is not plugged in, which should be useful for development. Alas, this doesn't quite work yet without the connection to the TI, I think I still need some pull up resistors and perhaps reset control from the microcontroller to get things going without the TI connection. However, if connected to the TI, it does work, i.e. the TI no longer sees the board.
  4. Yes exactly, that was a my feeling with some components. I ordered an original batch of 10 PCBs (this is my practice) back in 2018, and later learned that I don't like to install SMD LEDs by hand. I have in subsequent different projects learned a bit more, so I would not design the board anymore the way I did.
  5. Thank yuo @Ksarul this is very helpful! For my current boards it would be long straight pins, but in the future the saddle-mount would be the way to go for the next PCB revisions.
  6. Thanks, I may give that a go. I don't have a SIP socket, but I've got some DIP sockets I can repurpose, I'll give that a go.
  7. I watched recently a video by @jedimatt42 where he built a 32K SRAM expansion board for the TI-99/4A. Since I am in the process of building more of my ET-PEB boards, the video caught my eye. The method of adding POGO pins to extend the distance between vertically mounted PCB and the chassis seems like a very good one. So two questions for those in the know: - What would be a good supply for the edge connectors? The ones I have at the moment I got from eBay (some two years ago, need to try to locate some new supply) and they have quite short pins. - Where does one get those POGO single pin connectors? In fact, it would appear the ones in the video are not spring loaded POGO connectors but just one pin connectors. Mouser part # would be ideal :) Sorry if I'm repeating an existing topic here.
  8. Thanks, these are good comments! I also don't know if there ever were serious plans to have a GPL based processor, but in the wonderful world of FPGA design these things are possible, so why not give it a go... Since I wrote the last message I updated the GPLS instruction a bit more, it now also handles directly VDP address loading and indirection in the cases of VDP accesses. It's a bit ridiculous, it now occupies 30+ states. But an interesting exercise nevertheless. I did take a look at your design - very interesting and good reference material! I am in the process of adopting a partially microcoded approach, so that I can hopefully do the microcode implementation incrementally, without necessitating the creation of an entirely microcoded processor from the start. As I was looking at your design, I noticed that your microcode (the array "pla") is not clocked. I wonder if it maps to block RAM during synthesis? I am going to attempt to make a clocked design for the microcode ROM, to ensure that the microcode will indeed be in ROM (i.e. initialised block RAM). I am planning to make the microcode quite wide. I noticed that in your design you have a separate constant array, and the microcode only contains an index to the constants. That makes sense in keeping the microcode width smaller, but in order to accelerate GPL the microcode needs to generate a lot of constants, so I am going to just have a 16-bit field in every microcode step just for constants. That saves one level of indirection (a multiplexer) during the decode phase. It appears that I'm going to need at least: - a 3 bit field to choose ALU arg1 (my CPU core has registers as ALU inputs) - a 5 bit field to choose ALU arg2 - a 4 bit field to choose ALU operation - a 16-bit field for constants (which can be directed to either arg1 or arg2) - a 8-bit field for next CPU state (planning for max 256 words at the moment, easy to extend if necessary) - a 8-bit field for next CPU return state (to support microcode "subroutines", I already have this concept in the hardwired design) - a 8-bit field for conditional next CPU state - a field to choose whether the "next state" or "conditional next state" will be the next state, this will probably take 4 bits or more - a bunch of 1 bit fields to trigger the loading of ALU output to the internal registers: PC, data write, temporary 1 or temporary 2, effective address etc. Probably around 8 overall. All these together mean that the microcode is going to be something like 60 bits wide, maybe more. Multiplies of 18 bits map well to the block memories, so I might go with 72 bits first.
  9. Wow it's been almost two and a half years since I updated this thread... I'm now building three more boards in one go, since it seems I will be shipping out a few. It's quite a project to build these things, although building multiple boards simultaneously does speed up the process, as I only need to find once the components and locate their places on the boards. As I was looking at the chips I have in my shelf (well in various somewhat unorganised boxes really) I started to remember where I was in the project. I was trying to choose which microcontroller to use, from a few pin compatible chips. I originally went with chip with 32K Flash ROM and Cortex-M3 core, but quite soon learned that the 32K was going to be a squeeze for the firmware. My choice became easier since as I was looking at how many chips I have, there was only one model where I had three chips with more than 32K Flash. So I went on and built the boards with a processor I had not tested before. I just got the first board fully populated and tested, the firmware modified to support this new chip - and it worked on the first go! And when I say it worked, I mean that it worked to the extent the previous firmware worked - I probably want to spend a little time improving both the firmware and the DSR code. I was able to load basic programs from the SD card, and both tests for 32K RAM expansion and SAMS memory worked. The funny thing is that as I was building these, it almost felt like building a kit. It's been such a long time I worked on these that I had forgotten where I was, so I was re-discovering my own design as I went , referring to the schematics and BOM the same way as if I was following a kit.
  10. Now during the holidays I had some time to work on the icy99. I've been toying with the idea of adding GPL acceleration capabilities to the CPU core. As it was rumoured that there would have been the idea of having a CPU actually running GPL as its machine code, I though perhaps I could work on that a bit. I've been looking at an incremental approach, of adding some new instructions which would accelerate key operations of GPL interpretation. So I added two new instructions, one of them I am calling GPLS and the other MOVU. GPLS is a GPL operand address decoding instruction. It handles in one instruction most of the decoding job done by the routine in ROM at addresses >077A to >082C. Due to the incremental approach, I've arranged the instruction so that it will branch to ROM routines to handle the parts it does not yet do. Still it does the work of around 25 instructions in one go. It is much faster than the equivalent TMS9900 code since there are no instruction fetch cycles, and all temporary values are held on the CPU's temporary internal registers. It only accesses memory to perform the necessary memory cycles. As one example, the instruction reads the value of R13 only once in the beginning to fetch the base address of the GROM currently in use, and then it fetches from GROM the operand address bytes as necessary, without re-reading R13. These gave me an opportunity to understand how GPL instruction operands are constructed. The instruction does this: In all cases the GPLS instruction writes to R1 the address of the operand and to R0 the value. The value is either a byte or word, depending on bit 8 of R5 (I use the normal bit numbering, not TI numbering, so bit 8 is the LSB of the higher byte of R5). Icy99 CPU caches all writes to bit 8 of R5 in GPL workspace, so it always knows if this is a word or byte operation. Fetches the first operand byte from GROM. If the high bit of the operand is zero, this is a direct short operand, and the remaining 7 bits are an offset to the scratchpad area. In this case GPLS fetches a byte of word from scratchpad. It supports unaligned memory accesses, so it properly fetches 16 bit words from odd addresses. If the high bit is one, the operand is longer and more bytes from GROM need to be fetched. GPL supports 7 bit addresses in scratchpad, 12 bit addresses starting from address >8300, and 16-bit addresses, also offset from >8300 which is a bit weird. GPLS instruction also understands the use of index option, and will read a 16-bit value from an unaligned address in scratchpad to get the value of the base address, and the direct address is added to this. There are currently three cases the instruction does not yet handle, and branches to ROM if a) the address 837D is read from (this is a magical address, causing a write to VDP memory using X and Y coordinates), b) if the memory read is from VDP memory or c) the indirection is used. In all of those cases a, b and c most of the preprocessing is done, though. I also added the MOVU instruction, which has this format: MOVU *Rx,R0 where x can be from 0 to 7. MOVU performs an unaligned byte or word read operation (depending on bit 8 of R5) from the address pointed to Rx to R0. If the operation is for a byte, it will sign extend it to R0. Thus the read byte will end up in the lower byte of R0, unlike with MOVB which always deals with the high byte. Even if these are small changes to only one routine, this simple Basic program runs 10% percent faster: 10 FOR I=0 TO 1000 20 PRINT I;" "; 30 NEXT I I needed to add 18 new states to the state machine of my TMS9900 core to support these new instructions. That is a big addition, since the entire TMS9900 instruction set occupies 96 states in my implementation. Doing these changes was very time consuming; if I want to continue on this somewhat obscure avenue of speeding up GPL I probably need to move to a microcoded architecture, since implementing instructions of this complexity makes the CPU logic very complex quickly. For this super CISC system a microcoded architecture would only add instructions to microcode ROM, instead of adding new logic. Still, it was interesting to understand a bit more of the inner workings of GPL.
  11. Yes that's a good point. With multiple ROM pages (I suppose this would initially apply to FPGA system) the original ROM could always be provided as one option. I am interested in understanding how the user experience would change if the GPL was optimised, ultimately what the performance would look like if GPL was machine code of a CPU running in the FPGA. For GPL content, the test cases would be TI Basic and Extended Basic, also RXB Basic. Doing GPL optimisation would not make any difference to a lot of recent programs, which to my understanding have mostly been developed in assembly.
  12. Thanks for these comments! I have read a bit more source code, mainly looking at decode in general (as discussed in the first message here), the arithmetic operations, storing of results (>228) and GPL addressing modes (from >077A onwards). The move point you mentioned I hadn't read. In terms of new capabilities, it would seem there would be a lot to gain from being able to have direct 16-bit read/write access to the VDP address pointer, as well as having instructions to read and write 16-bit quantities to the VDP. These would not require CPU modifications, just small changes to the VDP. The existing 8K ROM space is an interesting limitation. I'm thinking there are a few different paths to accommodate over overcome the ROM size limitation: 1. Icy99. Since this is a FPGA which is not the original console, anything goes, as long as TI-99/4A software works. Extra instructions, higher clock speeds, multiple banks of console ROM, etc. 2. Real iron, updated ROMs. Since modifying console ROMs would probably be necessary, I suppose by the same token one could install larger ROMs and have multiple pages of ROM. This would make improvements a lot easier without breaking compatibility with existing software. 3. Real iron, existing ROMs. For certain things, such as speeding up TI Basic, it should be possible to make a cartridge which would contain a new main loop for GPL processing. Or perhaps this could be done in a DSR. Either way, it could be applied to an unmodified console. However, getting any speed benefits would probably be hard, as without any modifications the software updates would be constrained to having to execute from 8-bit wide memory. The algorithmic improvements would really have to be good to overcome break pedal imposed by 8-bit memory. 4. Real iron, existing ROMs, compile GPL to machine code. I don't know if GPL compilers exist, but this could be one potential avenue. It would result in pretty massive code size expansion, so one would probably have SAMS memory installed. Out of these, for me #1 is clearly the easiest choice for me to get going. By implementing a couple of extra instructions and additional features I would save machine code space in the 8K ROM, making it possible to retain existing entry points while modifying the ROM.
  13. Now got the Minimemory GPL code I assembled with xga99.py loaded on the icy99 and it seems to run fine. Icy99 does not yet support RAM at >7000, so need to enable that in theory, although I don't know if I need that since 32K RAM expansion is there. Now that I have a meaningful GPL program to play with, I hopefully can get an idea on what are typical GPL instruction sequences look like to understand where the low hanging fruit is for performance optimization in the interpreter. Minimemory does not need optimization though
  14. Which version of ULX3S you've got? I haven't yet written instructions anywhere on how to get the icy99 running on an ULX3S. Just let me know if you need some help with that. Super briefly, if you want to replicate my environment you need to have a micro SD card containing couple of python files, and a directory structure containing ROM & GROM images as well as the bitstream file for the FPGA. You also need to setup the ESP32 so that you can communicate with it, i.e. provide WIFI SSID and password, after which you can use Micropython WebREPL to communicate with it from a browser, something like: http://micropython.org/webrepl/#192.168.0.123:8266/ Where you replace 192.168.0.123 with the IP address of the ESP32. Once connected to the ESP32, you issued two commands: import osd osd.run.load_roms() After these steps the system is up and running. The "import osd" loads the python script to get everything going. It initialises the FPGA and loads the ROMs, but currently there is a problem in the system and the ROMs need to loaded again to get going. You also need a keyboard which supports PS/2 protocol. The keyboard is connected to the USB port using a USB to go adapter, I am using the Steelseries 6GV2 gaming keyboard. It has a USB cable, but it also operates in PS/2 mode through the USB cable, which is a requirement since there is no USB host functionality.
  15. As discussed a little yesterday in the Pandemic club 4A zoom call (thanks for the interesting discussion!) I started to look a bit how the GPL interpreter could be optimised. My original idea was to add some instructions to my FPGA processor core to speed up the interpretation with special purpose instructions, but as I started to look at the code it's quite clear that a lot can be achieved with normal code optimisation. @RXB mentioned that there has been a discussion with @Tursi about this topic. I somehow recall seeing that thread myself, but couldn't easily find it (which is probably my fault). As an obvious optimisation, instead of the multiple levels of tables, the GPL instruction decoding could be improved at the cost of using some more memory simply by having a 256 entry lookup table (occupying 512 bytes). For that part I could create a new instruction which could combine a few TMS9900 instructions, in pseudo code: // Address 0x78 MOVB *R13,R9 JGPL @TABLE,R9 // Here JGPL would be a new instuction, something like below. // The instruction would only perform 2 memory fetches: Read R9, and fetch the jump vector from TABLE. BANK 1 // Switch bottom 8K to a new bank, which has the jump table MOV R9,TEMP // Temp internal register SRL TEMP,7 // TEMP >> 7, shift to a word index MOV @TABLE(TEMP),TEMP // Fetch from table BANK 0 // Switch bottom 8K to normal bank B *TEMP In the arrangement above since the opcode would be passed to the new instruction JGPL, that instruction could also be developed further to understand some GPL instructions directly, executing them directly by the CPU instead of TMS9900. Many GPL instructions are quite involved, so it would best to be able to incrementally improve things, for example starting with branch instructions which seem to be rather simple. I also realised that I am jumping the gun - I should try to look at some GPL code before going to optimization phase to understand how things work. To that end I started using xga99.py to assemble the GPL code for Minimemory cartridge, as a test. Also since I think this a very cool cartridge which could be integrated and expanded in interesting ways in both my icy99 and StrangeCart projects. So I got the GPL source code for Minimemory from Thierry's excellent TI-99/4A tech pages. I guess that code is for his GPL assembler. But I wanted to use the xdt99 package. So I started to assemble the source with xga99.py, like so: xga99.py --aorg 6000 mmg.gpl -L mmg.lst I quite quickly ran into a few problems, due to differences in syntax, for example: The AORG directive in xdt99 does not accept addresses higher than 8K. This causes a number of problems, because there is a hole in the code, i.e. it AORGs to >70AC skipping a bunch of bytes. I guess I have to manually fill that range with some bytes. The multiplication instruction in the source is MPY, but xga99 uses MUL. Not a biggie. Many lines in the code contain comments (which is great) after the code. I have never understood why the comments don't start with a special character like semicolon or something, that would make parsing easier for the assembler and it could probably also prevent some mistakes. Anyway, xga99 could not assemble a number of lines because the comments were separated by just a space. I just removed those comments after the code (by moving them to a separate comment line). The HTEX instruction (in a FMT block) escapes hex bytes differently, simple change: from HTEX '[>0A]' to HTEX >0A Some other opcodes also are different: CAR -> CARRY, PARS -> PARSE, DCGTE -> DCGT The source code uses the BIAS command also outside a FMT - FEND block, it appears to specify a constant to be added to strings specified with the STRI directive. The source I used has first BIAS >60 to set the TI Basic character code offset. I did not find a way to replicate this functionality in xda99. The advice goes: "use the source, Luke". And so I did, and created a new directive STRI60 for xda99, as follows. It's hack for sure, but I didn't want to enter the text as BYTE statements. * Original source (disassembled and commented by Thierry) BIAS >60 G6E1A STRI "ILLEGAL TAG" G6E26 STRI "CHECKSUM ERROR" ---------------------------------- * Modified source for xda99: *EPEP BIAS >60 G6E1A STRI60 "ILLEGAL TAG" G6E26 STRI60 "CHECKSUM ERROR ---------------------------------- * xda99.py has been modified to support the new STRI60 as follows: # EP 2020-12-13 added new STRI60 operation to add the screen offset to each byte. # Used for Mini Memory porting @staticmethod def STRI60(asm, label, ops): asm.process_label(label) text = ''.join(asm.parser.text(op) for op in ops) asm.emit(len(text), *[ord(c)+0x60 for c in text]) And this is roughly where I am at the moment. I am comparing the generated GPL binary image to the original, and now the first >770 bytes match (except for the pointer to >70AC due the AORG stuff, need to come up with a solution for that - probably I'll just fill in the empty range with some bytes) to get to 70AC.
  16. Yes, I really like the F18A. But since it has just over 16K of VRAM, while the 99x8 chips support 128K, on the VRAM extension part following the 99x8 model makes sense to me. The way Matthew built the F18A seems to have been in a way where the F18A extensions use registers which are not used by the 99x8, so at least partially it is possible to support both. I also have some ideas of my own that I want to try out. But one step at a time.
  17. Thanks @Nick99 for these comments. To be honest with you, I haven't yet studied the 9938/9958 in much detail yet. I wanted to go above 16K of VRAM and I wanted to do that in a way which is compatible with something, otherwise it becomes just an obscurity. But my plan is to bring in many more features. Since I am not familiar with the 80 column cards or TI-99/4A software available for them, could you provide me with some pointers please?
  18. Since ZX Spectrum Next is on the list I need to put my icy99 TI-99/4A FPGA implementation to the list as well. It currently runs the test in 20 seconds (CPU core clock at 25MHz, but the cycles are not directly comparable with TMS9900) both using TI Basic and Extended Basic. Obviously I need to push that below the 12 seconds the ZX Spectrum Next is doing here.
  19. A bit more progress, I have now a strange mixture of features - development still on-going: normal 40 column text mode 40 column text mode with 26.5 lines (as in the 9938) 40 column text mode with 30 lines (as in the F18A) 80 column text mode with 24 lines 80 column text mode with 26.5 lines (as in the 9938) 80 column text mode with 30 lines (as in the F18A) The 26.5 lines mode is enabled as in the 9938, i.e. setting bit 7 of R9. The 30 lines mode is enabled as in the F18A, i.e. setting bit 6 of R49. As I wrote before, there is is now 64K of VRAM. Need to test that it is actually there... A question: I know that F18A is locked on reset, and thus extended features are not there before they're enabled. But what about 9938? I guess with it things are not locked. Like I wrote in the past, the TI99/4A ROM initialises the unused bits in R0..R7 in a way which moves some of the screen tables beyond the 16K range with the "9938" in the icy99. I now work around with this by having a new register 63, which must be written to in order to have the icy99 VDP in extended mode, but this is not compatible with any software using F18A or 9938 in 80 column text modes. I suppose I could just modify the console ROM and/or GROM to be compatible with both 9938 and TMS9918... so that after normal reset the screen pattern definitions or character areas do not move above 16K range understood by TI Basic.
  20. Continued to work on the icy99 some more, with the goal to release some FPGA memories I was using for low bandwidth stuff like GROMs. That also meant some changes to the boot up method - now the ESP32 controller on the ULX3S first initialises the FPGA, and then writes to SDRAM the console ROM and GROM contents. That also had the side effect of slowing down the system somewhat, although I am still running at around 3.5x the original speed. I will probably bring back the cache as a configuration option, since that would dramatically increase the CPU speed. But right now I am not aiming for max speed. Once I was done with that, I wondered how to improve the VDP a little, in light of the interesting software that's available. I decided that the first thing to do was to increase the amount of VRAM, and now it is 64K. On this specific FPGA board I could make it much larger, but I was thinking that 64K or 128K would already be good. I was wondering what would be the best way to make the memory available, and settled with the obvious approach of going along the lines of V9938 VDP. That also means that I can support some of the existing features such as reading scanline position over standard interfaces. Anyway, the 9938 has quite a bit of functionality, and for now I was just looking to have a way to support more than 16K of VDP memory. I added new VDP registers to support 17bit (128K) VRAM addresses: 10, 11, 14,15,16,17,19 - not all of them work yet. I also added status register 1 (7 to go, the 9938 has 9 of them). Anyway, as I was playing with this, I pretty much instantly ran into the problem that TI ROMs initialise some of the unused bits in the TMS9918 to ones, instead of zeros. The 9938 uses those unused bits, but is compatible with the TMS9918 if they're left at zero. I temporarily added a new register 63 which enables 9938 mode, and on reset the system boots in TMS9918 mode. The extra VDP memory is still available, but the address register extensions are not used for screen tables before the VDP is in 9938 mode. I expect there to be some incompatibilities with existing software when the extended registers are enabled. For example the megademo (Don't mess with Texas) also has a phase - when going to scanline effects - where it writes to R15 the value of one, causing the status register 1 to become active, and thus breaking a lot of stuff since the software thinks it's reading register 0 when actually it is accessing register 1. I fixed this by also making the extra status register only available in 9938 mode. I haven't done enough reading of the 9938 manuals, perhaps there is a standard way of making it look like a TMS9918. One annoying problem I am lately having is that sometimes the DVI output generated by a particular synthesis run does not show stably on my monitor. It is weird, since a typical synthesis report shows that I have quite huge margins (the 125MHz DVI clock could run at 200MHz).
  21. Never mind, I restarted the editor in 80 column mode, and I can see the commands which were not visible in 40 column mode. Didn't realize that in the command mode (or whatever it is called) the command save and load are there, just need to be entered in upper case as single character commands. Makes sense. And the 80 column mode works on the icy99, so all good!
  22. Now that my icy99 FPGA core is gaining increasing functionality, and it works with TIPI, I am starting to discover the world of TI-99/4A software outside the domain of cartridges. So here goes a stupid question: How does one use @F.G. Kaal's editor? This is really a beginner's question for sure. I have so far mostly created programs for the TI-99/4A using xas99.py cross assembler on a PC/Mac/Linux box. Examples: how do you save? how do you load text? Etc. I assume that key mappings are like editor assembler. So FCTN+9 is an esc command and seems to get me into a command mode? (I launched EDIT40 with TIPI, i.e. from TI Basic call tipi("DSK1.EDIT40") so no editor assembler involved here. I looked at Fred's web site, but I didn't find documentation about basic editor usage. I also loaded the assembler source code, but understanding usage with that seems to require a fair amount of reading of the source.
  23. Yes, time is the problem, isn't it. Some of the things, such as detecting sprite collisions, becomes very easy with the original approach, just a simple four input logic gate will do the trick. 112KB is quite a lot of memory already. I haven't optimised internal memory use too much yet, currently the icy99 uses around 96KB but that can be reduced easily. For instance system ROM and GROMs are stored on-chip, although that is not necessary. I am planning to increase VRAM to 64K. That would be a sizeable increase and enable some further extensions (along the line of 9938/9958/F18A). Having said that I am enjoying the simple 80 column mode a lot. These are very cool projects you have lined up, good luck with them !
  24. One more thing - for me "python" runs python2, I am wondering does it link to python3 on your development system? My understanding is that just "python" normally would launch python2 and python3 needs to be explicitly specified.
×
×
  • Create New...