Assembly on the 99/4A

[apersson850]

I agree. I would not use that Compare instruction for this purpose unless my available memory is -2 bytes.

[matthew180]

13 hours ago, Tursi said:

C *R2+,*R2+, assuming it's running in 8 bit RAM, registers in scratchpad, and R2 points to memory that triggers the multiplexer ...

 

This, for sure.  Just to reiterate, not only do you need to worry about where your workspace is located (ideally in 16-bit RAM), but the value in R2 being incremented is used as a pointer in this scenario, twice!  And as Tursi pointed out, taking that integer value as a memory location will almost certainly *not* be an address in 16-bit RAM, and will thus trigger wait-states.

 

Another not so obvious nuance with this method is that the location could be a memory mapped device, like the VDP, sound chip, or other, so IMO it is not safe to use unless you know exactly what values are going to be in R2.

 

24 minutes ago, Vorticon said:

Clever! Thanks for the explanation. It's a rather obtuse way of doing things, so there had better be a good reason to do so. In my world clarity of code trumps maximum efficiency in most situations. 

 

Yup, totally agree.

 

18 minutes ago, apersson850 said:

I agree. I would not use that Compare instruction for this purpose unless my available memory is -2 bytes.

 

Even then, I would start looking for other places to free up 2-bytes.

 

[senior_falcon]

The McGoverns of Funnelweb fame did an article about assembly that showe some neat tricks, with C *R2+,C*R2+ being one f them. As I recall, much of their focus was conserving registers, which you can low on, even with 16 of them.

As far as clarity, 

C *R2+,*R2+ add 4 to R2 

And then there is no mystery about what is happening.

[Asmusr]

I would use A R4,R2 where R4 contains the value 4 if I was to do this in a tight loop. Saves 4 cycles compared to AI R2,4.

[+TheBF]

1 hour ago, senior_falcon said:

... much of their focus was conserving registers, which you can low on, even with 16 of them.

That's why God invented stacks.  

[apersson850]

And the other god invented the ability to have multiple workspaces.

[senior_falcon]

Polytheism in the retrocomputing world. Who would have guessed?

[+OLD CS1]

32 minutes ago, senior_falcon said:

Polytheism in the retrocomputing world. Who would have guessed?

Every time I let out the magic smoke is an offering to my computer gods.

[senior_falcon]

Good idea to keep them appeased.. You don't want the computer gods  to smite you.

They have done that to me many times.

Edited March 21 by senior_falcon

[retrodroid]

On 3/20/2024 at 1:43 PM, matthew180 said:

On 3/20/2024 at 1:25 PM, apersson850 said:

most people still active with the machine are pretty much experts by now.

 

There are actually a lot of people taking their first steps into assembly language around here.  The thread was started to help someone doing exactly that, and part way through (around 30 to 50) someone else picks it up starting from zero, and actually writes his first assembly game (Airshack, RIP).

I also benefited greatly from this thread a little over a year ago now - it got me started on Assembly Language. I now have a wonderful game that is close to completion and have thoroughly enjoyed the learning experience required to create it.  Never would have happened without all the assistance that you all have generously provided in this thread and others, so thanks!  🙏  

[Tursi]

20 hours ago, matthew180 said:

Another not so obvious nuance with this method is that the location could be a memory mapped device, like the VDP, sound chip, or other, so IMO it is not safe to use unless you know exactly what values are going to be in R2.

We actually ran into a case like this in the GCC port - the variable it was adding to was a pointer pointing to cartridge memory, so the 'add' caused a bank switch.

 

[+dhe]

I was re-re-reading the VDP Programmers guide. I noted three additional manuals were listed.

I found one, attached. I also noted they mentioned the Advanced VDP.

 I found a patent application from 1992 - attached.

 

 

SPPA004A_9928-29_9118-28_Interface_to_Monitors.pdf US5089811.pdf

[matthew180]

The interfacing document I have not seen before.  That is a whole lot of electronics just to get a decent video output from the 9928/29.  It is no wonder that the output from systems that used these VDPs was always crappy.  It also came late enough to include the 9128 and 9129.  Note that the name of the file incorrectly includes the 9118.  The "_9118-28_" part should actually be "_9128-29_".  The 9118, like the 9918(A) only outputs composite video, and the electronics in that document require the component output only available in the 28/29 chips.

 

As for the patent, I'm really surprised that was issued.  It was submitted in the late 80s (89) and not issued until 1992.  All the concepts included were "old-hat" by the late 80s, and by the early 90s video capabilities had well surpassed what is described (some more sprites, a color palette, I think on-board audio, and a few modes to get 512x240 with restrictions).  Many coin-op games from the early 80s had better capabilities in some cases (usually with 320x240 resolution standard).  Even the 9938 has better capabilities, and came out much sooner than when the patent was filed.

[Tursi]

that might explain why TI wasn't suing people left and right for cloning the chip

 

[+Vorticon]

Is the data stored in the AMS pages preserved when when the mapper and card are turned off?

[RXB]

37 minutes ago, Vorticon said:

Is the data stored in the AMS pages preserved when when the mapper and card are turned off?

No the memory of the SAMS or AMS are not saved it you turn off the power.

Does not matter if the mapper is on or off, the data is still there as long the SAMS or AMS has power. 

Does not matter to the data if the DSR is on or off, does not matter if in MAP Mode or PASS Mode the data is still there with power on. 

If the DSR is on you can use XB or TI Basic (EA Cart) to change RAM memory pages. 

 

RXB can talk to 16Meg of RAM pages in the SAMS.

[+Lee Stewart]

39 minutes ago, Vorticon said:

Is the data stored in the AMS pages preserved when when the mapper and card are turned off?

 

It should be there until you turn off the computer.

 

Also, there is really no reason to turn off the mapper unless you really want the start-up, transparent mode. I mentioned before that, once initialized in fbForth, the mapper is never turned off.

 

...lee

[+Vorticon]

2 hours ago, Lee Stewart said:

Also, there is really no reason to turn off the mapper unless you really want the start-up, transparent mode. I mentioned before that, once initialized in fbForth, the mapper is never turned off.

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.

 

[+TheBF]

48 minutes ago, Vorticon said:

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.

 

Well... you could leave the mapper on and simply map in the "pass-thru" page for that window address if that is easier. ?? 

I think for the window at >2000 you map in page 2. (ie: the value it is initialized to) 

 

[+Vorticon]

56 minutes ago, TheBF said:

Well... you could leave the mapper on and simply map in the "pass-thru" page for that window address if that is easier. ?? 

I think for the window at >2000 you map in page 2. (ie: the value it is initialized to) 

 

Yeah it works tha way too.

[apersson850]

When I've used extra memory for the p-system I've used cartridge space addresses, 6000-7FFFH, since they aren't used at all by the p-system. Can you map SAMS to present memory there, or is it limited to show it at the normal memory expansion addresses, 2000-3FFFH and A000-FFFFH?

[+TheBF]

47 minutes ago, apersson850 said:

When I've used extra memory for the p-system I've used cartridge space addresses, 6000-7FFFH, since they aren't used at all by the p-system. Can you map SAMS to present memory there, or is it limited to show it at the normal memory expansion addresses, 2000-3FFFH and A000-FFFFH?

As it turns out no.  I wanted to do the same thing. 

[hhos]

56 minutes ago, apersson850 said:

When I've used extra memory for the p-system I've used cartridge space addresses, 6000-7FFFH, since they aren't used at all by the p-system. Can you map SAMS to present memory there, or is it limited to show it at the normal memory expansion addresses, 2000-3FFFH and A000-FFFFH?

The only thing preventing this usage of memory space in the 6000-7FFF range is the fact that the memory control circuitry on the SAMS does not bring that out.  You might want to pay a visit to the SAMS thread for more information.  It should also be noted that when the SAMS registers, or any other DSR device, are not being accessed you should be able to use the RAM space at 4000-5FFF, should it be similarly decoded.

 

HH

[+Vorticon]

46 minutes ago, hhos said:

The only thing preventing this usage of memory space in the 6000-7FFF range is the fact that the memory control circuitry on the SAMS does not bring that out.  You might want to pay a visit to the SAMS thread for more information.  It should also be noted that when the SAMS registers, or any other DSR device, are not being accessed you should be able to use the RAM space at 4000-5FFF, should it be similarly decoded.

 

HH

Can this be fixed on an existing card?

[hhos]

I posted some schematics at

Two of these should give some idea of what is needed to add the function you want.  I also included switches for 0000-1FFF and 8000-9FFF which would be somewhat more problematic.  I wouldn't recommend trying those without significantly altering the console.  There is also a switch to shut off the output of the mapper.  These could be implemented on an existing board, but I will not be doing it.  For one reason I do not have a SAMS board.   Trying to work out how to alter a board without having one to apply an ohmeter to doesn't sound like a good idea to me.🙂   Another reason is Its dependence on SRAM is expensive, and has much less promise for capacity than a DRAM solution, so I won't be getting one.

 

HH