Standardized 'libraries' for Assembly?

[Victim_RLSH]

I had to scrap Gravity Ball and start over because I was running out of memory and my physics were janky as f***. I was using almost identical code in multiple areas to do the same jobs, the program was disjointed and hard to follow, and the code I had to look over was huge, over 1000 lines with labels and data.

I'm writing my own personal 'libraries' similar to a function library in C that I can load in on a single line with INCASM directive with standardized parameters that I can pass to and from the functions. This should make everything easier to understand and consume a LOT less memory and time going back and forth between parts of the program. I'm also developing a "flip book" doc that I can quickly reference on a 2nd screen or monitor (I have to upgrade to a later version of Win 10 ARM for Pi 4 to do this, I'm using one a few months old that doesn't support the dual monitors, but the new one does. Getting a new Win 10 install on a Pi 4 is a monumental pain, worse than trying to code 6502...)

Is there a collection of .asm routines like this already put together for the vic, besides the Kernal calls?

[Victim_RLSH]

Here's an example.

Program code for JoyStick.asm

JoystickS1 = 37137 ; Set data direction registers at 37139 to 0
JoystickS2 = 37152 ; and 37154 to 127 before attempting to read joystick

StickUp$ = 4 ; read these 4 values from JoystickS1
StickDown$ = 8 ; these bits are INVERSE. Bit with be 0 on read from stick
StickLeft$ = 16
StickFire$ = 32

StickRight$ = 128 ; read this value from JoystickS2, also inverted


InitJoystick LDA #$00
STA 37139 ; Set data direction registers to allow reading stick
LDA #127
STA 37154
RTS ; return from InitJoystick

ReadJoystick LDA JoystickS1 ; Inverts joystick data and copies it into 1 byte
EOR #%00111100
AND #%00111100
STA JoyData$
LDA JoystickS2
EOR #%10000000
AND #%10000000
ORA JoyData$
STA JoyData$

RTS ; Return from ReadJoystick


JoyData$ BYTE $00


Pic from flip book for use as a quick reference

Now I can just add the routine inline to my Assembly program with INCASM "JoyStick.asm" and it won't be cluttering up the listing. I will also have a predefined memory usage and clock cycles for the routine.

[beamrider]

I think most people programming on the Vic in assembly like to write their own code from the ground up. e.g. there is the VIC-SSS sprite library by Robert Hurst, but it didn't get much traction.

[tlr]

In general, size-coding and the concept of (soft loaded) libraries does not go well together. For example you'll lose a lot of boundary optimization opportunities. For size-coding you'll want to keep any abstraction strictly in the source, perhaps just as comments, not to compromize the optimized binary implementation.

It's a useful approach to implement an initial rough version though, and then gradually optimize it as you go along.

[Victim_RLSH]

Yeah, I can't have too much in each one. For instance in the above joystick routine I could have added something to push the current contents of the Data Direction Registers onto the stack, set them, read the stick, then restore them. That would have added size and execution time and if the keyboard isn't needed it is OK to jack up keyboard scanning by not resetting the DDRs. An ultimate savings of space would be to just initialize the DDRs, read the joystick inputs, and just test for the inverted bits in your program. It's a tradeoff between avoiding a mess and using a bit more memory. A balancing act I still need to master...

[Mike]

I was using almost identical code in multiple areas to do the same jobs, [...]

There's the opportunity for you to gather all those code sections and replace them by a single subroutine that gets called by JSR as a stand-in in all those places where the code sections resided before. If the code sections do not perform exactly the same action, but are similar enough, take a look at them how they could be parametrized to obtain a single subroutine as replacement.

[...] the program was disjointed and hard to follow, [...]

If you proceed as per my suggestion, a call hierarchy should emerge. Sort the subroutines by their level in that hierarchy. If there shows up code that never gets called except on program start, that's your main loop/procedure.

[...] and the code I had to look over was huge, over 1000 lines with labels and data. [...]

My suggestions above should help you to regain an overview.

[...] Is there a collection of .asm routines like this already put together for the vic, besides the Kernal calls?

Sorry I can't be more specific with a question of such a broad scope like yours.

A joystick routine on the VIC-20 isn't exactly rocket science. You read the two port registers (with possible extra handling of the data direction registers), mask out the relevant bits and there you go. This isn't a routine that makes or breaks your code.

Employing the KERNAL jump table is surely a good idea to get stuff going.

[chysn]

There are quite a few factors that work against something like the C Standard Library for, specifically, unexpanded VIC-20 development.

libc is compiled, and compilers are smart. So if you don't use a function, it usually won't find its way into the executable. Assemblers, on the other hand, just slurp everything in and add it to the executable. So this leaves you inevitably optimizing features out of the library, which sort of defeats the purpose of a standard library.

Each developer for the unexpanded VIC-20 probably has their own toolkit of various routines. I certainly do. And I'd love to say that I can re-use them from project to project. But no, the best that can be said is that I sort of re-use them. There's always something different enough that the routines need to be bespoke every time. You can't have bits of code sitting idle. For example, the joystick routine you provided might not be the same every time. Sometimes you might only want to return a single direction, or debounce the joystick after every movement. It depends on the requirements of the project, and a "standard" joystick routine might be too long or not do enough.

Believe me, I started out a couple years ago with grand ideas of applying fancy design patterns to the VIC-20 as though nobody had thought about doing that. And my machine language design is still heavily influenced by C. Surely, many of the everyday things just get easier with practice, and with practice you won't worry about a standard library so much. But the fun parts, algorithms and data structures (more so data structures) are going to be totally different from project to project.

[Mike]

I was using almost identical code in multiple areas to do the same jobs, [...]

If the code sections do not perform exactly the same action, but are similar enough, take a look at them how they could be parametrized to obtain a single subroutine as replacement.

Here's an example. In MINIMON, in one place, I need to add the same 16-bit value to two different pointers in zeropage:

Code: Select all

[...]
 CLC
 LDA zp_ptr
 ADC abs_temp_0
 STA zp_ptr
 LDA zp_ptr + 1
 ADC abs_temp_0 + 1
 STA zp_ptr + 1
 CLC
 LDA zp_adr
 ADC abs_temp_0
 STA zp_adr
 LDA zp_adr + 1
 ADC abs_temp_0 + 1
 STA zp_adr + 1
[...]

This needs 30 bytes. I rewrote it as follows:

Code: Select all

[...]
 LDX #zp_ptr
 JSR zp_X_plus_eq_temp
 LDX #zp_adr
 JSR zp_X_plus_eq_temp
[...]

.zp_X_plus_eq_temp
 CLC
 LDA $00,X
 ADC abs_temp_0
 STA $00,X
 LDA $01,X
 ADC abs_temp_0 + 1
 STA $01,X
 RTS

This only needs 26 bytes in total and has accountable functionality being factored out into a parametrized subroutine with a meaningful name.

[groepaz]

libc is compiled, and compilers are smart. So if you don't use a function, it usually won't find its way into the executable. Assemblers, on the other hand, just slurp everything in and add it to the executable. So this leaves you inevitably optimizing features out of the library, which sort of defeats the purpose of a standard library.

That is not quite true. With the cc65 toolchain you get an assembler and a linker, and you can write library functions in assembler (in fact most of the libc is written in assembler) and of course you can link pure assembler code against a library and have it only contain the functions that are actually referenced. (64tass supports a similar technique, although with a completely different workflow)

[chysn]

libc is compiled, and compilers are smart. So if you don't use a function, it usually won't find its way into the executable. Assemblers, on the other hand, just slurp everything in and add it to the executable. So this leaves you inevitably optimizing features out of the library, which sort of defeats the purpose of a standard library.

That is not quite true. With the cc65 toolchain you get an assembler and a linker, and you can write library functions in assembler (in fact most of the libc is written in assembler) and of course you can link pure assembler code against a library and have it only contain the functions that are actually referenced. (64tass supports a similar technique, although with a completely different workflow)

I keep thinking I should try cc65 some time. Since the VIC-20 is one of its targets, might it already support some of the things the OP is asking about?

[groepaz]

Well, sure. Although using C is not a good idea for (unexpanded) VIC20 - but the assembler and linker is excellent

[bjonte]

In general, size-coding and the concept of (soft loaded) libraries does not go well together.

It's possible to write things that require specific optimizations in macros instead, if the assembler allows it. These can check for specific conditions like "only one column" or "no data" to provide special handling. For example, I have a memcopy macro that tries to generate the most reasonable code based on the size of the copy. I don't use binary libraries, but I have a lot of reusable code in source modules, sometimes in macros and sometimes as subroutines. But, in extreme cases, like cramming stuff into 1 kB or 3.5 kB some things may have to be completely tailored.

[tlr]

In general, size-coding and the concept of (soft loaded) libraries does not go well together.

It's possible to write things that require specific optimizations in macros instead, if the assembler allows it. These can check for specific conditions like "only one column" or "no data" to provide special handling. For example, I have a memcopy macro that tries to generate the most reasonable code based on the size of the copy. I don't use binary libraries, but I have a lot of reusable code in source modules, sometimes in macros and sometimes as subroutines. But, in extreme cases, like cramming stuff into 1 kB or 3.5 kB some things may have to be completely tailored.

True, although this doesn't really handle keeping track of the state of flags and registers which is very useful to skip redundant initializations. This can partly be solved by having several macros doing the same thing but requiring different initial values though.

As a side note, macros can also be useful for structuring code in inlined "subroutines" avoiding the need for real JSR/RTS subroutines.

[bjonte]

True, although this doesn't really handle keeping track of the state of flags and registers which is very useful to skip redundant initializations.

Yes, that's definitely a problem when optimizing heavily.

As a side note, macros can also be useful for structuring code in inlined "subroutines" avoiding the need for real JSR/RTS subroutines.

Yes, I like that approach. I rolled my own assembler and made it possible to call subroutines as if they were macros as well. That way a module can change its implementation from subroutine to inlined macro without the calling code having to know about it (provided the caller uses the macro syntax to call it).