Jump to content

Vorticon

+AtariAge Subscriber
  • Posts

    5,875
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Vorticon

  1. It's not free, just not needed while running an assembly program, at least based on @apersson850's memory map. It will need to be restored prior to returning to the host program.
  2. That seems to be the best path to me. The Mini Memory requirement in my view is probably the most universal solution to store the DSR. I have some serious reading to do...
  3. Right. So I assume that rules out creating a DSR for it. Mind you I have zero understanding of how DSR's are set up and programmed outside of just a very superficial general concept. Is there a document somewhere that has a reasonable explanation of how one might create a DSR?
  4. Now that would definitely be a good incentive. That said, I recently purchased an IDE drive card for the TI with an RTC which I'm planning on building it this week, and my hope is that there might be a way to use that as an additional drive in my p-system. It may not be as fast as a RAM disk, but this will offset by the fact that contents will obviously be non-volatile. But going back to the SAMS, since data can only be access through a 4K window at >2000 in the p-system, I have no clue how to get this scheme to work as an alternate code pool seamlessly, particularly since transparent 4K paging will be required for larger data or programs, not to mention that any screen I/O will corrupt the data while the card is active and will not be visible. I am intrigued enough to consider it, but it may be a little beyond my pay grade. If you want, perhaps you can give us an outline of how one could accomplish this for starters, keeping in mind that I am not engineer/developer anything and I only do this for the intellectual stimulation
  5. The update speed to the game map in such a game is important to keep play from dragging on. Remember that hypothetical map is too large to reside in main memory, so it's either a disk drive or SAMS. Imagine how slow it would be to constantly access the disk drive everytime a change is made... Now a RAM disk would be ideal I agree, but turning the SAMS into one is not a straightforward process given it's access limitations in the p-system. I'm happy enough with the SAMS as it stands currently 🙂
  6. Yes, but much quicker access by far. The way I see this used is to load data from disk and store it in SAMS at the start of a program, then subsequently access that data directly. Think of some kind of large game map for example updatable in real time. It will stay in SAMS instead of taking up standard system memory yet remain easily accessible. Or perhaps a large data set the requires some kind of transformation before storing back to disk. Again it can be easily accessed without affecting available memory for the main program.
  7. It has become very difficult to find genuinely knowledgeable and expertly written coding books in the modern era. This is where going to a brick and mortar book store and physically evaluating the books is essential. There is lots of junk out there sadly.
  8. The utility uses a packed array of bytes for data transfers back and forth and a transfer could be done in one pass provided there is a large enough array available. Otherwise it will have to be broken up into smaller chunks up to the maximum ram size of the SAMS. The Pascal program can then take care of converting the array to some other structure if needed. There is complete control over where in SAMS the data is stored or retrieved down to the byte level and consecutive pages are brought in as needed automatically, so different data sets can easily coexist.
  9. I'll have to come up with a timing test to accurate characterize what is going on here. Maybe it's my imagination 😁
  10. Here's a set of utilities for full access to the SAMS card on the p-system. I have plans for this
  11. Taking a closer look at the 4k memory block from >2000 to >3000 in low memory expansion, it seems that it does not have anything critical to the execution to an assembly program in high memory, so SAMS pages can be loaded through that window safely as long as that block is restored prior to exiting to the host program. I tested it and no problem at all. Now I can use the full SAMS capacity. Cool.
  12. Writing to the SAMS seems slower than reading from it. Is that a thing or something on my end?
  13. Can this be fixed on an existing card?
  14. Unlike regular assembly, in UCSD Pascal most of the expansion RAM is utilized by the system or the programs. The only "safe" place I found was the 80 col text screen location at >2000 to switch pages around and thus only 1920 bytes (80x24) of each page can be used . But I have to turn the mapper off to get back the original screen. Using any other base location will crash the system the minute the mapper is turned on. I am working on a system allowing large data sets to be stored in sequential pages using the >2000 base. Not quite working yet. But yeah usage of the SAMS is severely restricted in the pcode environment.
  15. Is the data stored in the AMS pages preserved when when the mapper and card are turned off?
  16. That's a new one to me. In this case I assume we have to use VARAVAIL and VARNEW to allocate the desired size?
  17. Sorry I did not get emails. Might have gone to the junk folder. Atlantis is on my list already when I get some time to update. Good game.
  18. Is there a way to pass arrays of different sizes to a single generic array parameter in a procedure call? Right now I have to create a Type declaration for an array of a specific size, declare an array of that type, and use it as a parameter in a procedure. The problem is that if I have a need for arrays of different sizes that can use the same procedure, I'll have to make Type declarations for each one as well as additional procedures to accept these new types. Obviously not a solution...
  19. Tested on real hardware. Works. 20240323_051644.mp4
  20. So based on what @Lee Stewart said above, it seems I was testing the memory contents wrong. I was writing to the test page and reading it back, and apparently that will always be equal regardless of whether the actual page exists or not. Using what Lee did where I write a value to the initialized memory location, change the page then test of equality did the trick. Not necessarily evident by any means particularly when Harrison was doing what I was originally doing myself. Here's the now working source. It's so fast that I'm not bothering with skipping testing at the 128K boundaries which would complicate things and rather just going through all the pages sequentially. .func samssize ;returns the number of pages available ;usage: sizeint := samssize .ref pcodeon,pcodoff,procret mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn on card sbo 1 ;turn mapping on li r4,16 ;page counter. skip over first 16 pages li r1,15 ;page/bank register value mov @2000h,r3 ;save contents of test memory location li r2,0ffffh ;test value mov r2,@2000h ;low memory location used for testing incpage ai r1,1 ;add page/bank starting at page >10 bank 0 swpb r1 mov r1,@4004h ;map address >2000 to page/bank c r2,@2000h ;did it write correctly? jeq endpage ;new page should not equal initial value swpb r1 clr @2000h inc r4 ;increment page counter jmp incpage ;try next page endpage li r1,0200h ;restore original mapping mov r1,@4004h mov r3,@2000h ;restore contents of test memory location sbz 1 ;turn mapping off sbz 0 ;turn off sams card mov r4,*r10 ;return page counter bl @pcodeon mov @procret,r11 b *r11
  21. But you are exiting the routine if the page is not equal to >994A. I'm confused
  22. I simplified my code a little, but still the same issue where any bank/page will work regardless of the size of the SAMS as verified by the debugger. I will have to try that on real hardware again tonight. .func samssize ;returns the number of pages available ;usage: sizeint := samssize .ref pcodeon,pcodoff,procret mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn on card clr r4 ;page counter li r1,15 ;page/bank register value li r2,0ffffh ;test value incpage ai r1,1 ;add page/bank starting at page >10 bank 0 swpb r1 mov r1,@4004h ;map address >2000 to page/bank sbo 1 ;turn on the mapper mov r2,@2000h ;write test value to >2000 c r2,@2000h ;did it write correctly? jne endpage swpb r1 clr @2000h inc r4 ;increment page counter sbz 1 ;turn off the mapper jmp incpage ;try next page endpage li r1,0200h ;restore original mapping mov r1,@4004h sbz 0 ;turn off sams card dec r4 mov r4,*r10 ;return page counter bl @pcodeon mov @procret,r11 b *r11
  23. I don't understand the part where you check the contents of the write. You initially write a test value to >E000, turn on the card, load >401C with the page you want to test, turn off the card, then do a compare between the original test value in R2 and the contents of >E000. You don't have mapping on, so writing to >E000 really is just writing to the original location and not the test page. And why are you turning the card off before the compare operation? What am I missing?
×
×
  • Create New...