The new fork of HuC

[Arkhan]

Yeah, it's good that some people with more curiosity and time to mess with it have proved that it can at least go somewhere.   We had toyed around with the idea of rewriting stuff at one point, but I personally am more wrapped up in the game writing than the tool writing, because... the tool writing is sometimes kind of boring, and working around it in assembly turned out to not hurt that bad.

How far away is a 6502 SDCC?  I could've sworn there was one.   

[elmer]

So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.

I've sent you updated versions of HuC and Squirrel that will get you back the sound again.

I've also sent the changes to Squirrel to Arkhan and TheOldMan so that they can decide if they want to change anything before they release a new version.

In the meantime, the changes to HuC are checked into github, and here's the latest build ...

https://www.dropbox.com/s/abch2ar3krr4s9u/huc-2016-11-22.zip?dl=0

This build still won't work with the old version of Squirrel's HuCard player, but it'll work with the System Card, or if someone uses a different sound driver, or no sound driver at all.

How far away is a 6502 SDCC?  I could've sworn there was one.

At least a year. Progress has stalled (at least on my side).

[elmer]

I'm looking at the HuC graphics library function "fade_color()".

Has anyone tried to use this?

The code looks like it has a major bug in it, and I'm tempted to just remove it if people can't confirm that it works.

[Bonknuts]

There's another function.. load something or other that has a bug in it. Rov' would probaby remember (loadbat or something like that?). I just remember that huc users were avoiding it, using loadvram instead (I think). Maybe someone else can confirm.

[nodtveidt]

I think you might be referring to load_sprites(), which wasn't buggy per se, it just wasn't documented very well so some people didn't quite understand how to use it. Originally, Bt was using load_sprites() for sprites that were smaller than 32x64 and it was causing major slowdown in his run-n-gun game. I just told him that it's a function intended to load multiple large sprite blocks and that he should use load_vram() for loading sprites that are smaller. He made the change and the performance of his game returned to normal. This is the only thing I can think of along these lines.

[ccovell]

I hope I'm not derailing the topic, so if I am, please let me know.

SHORT: ASM-only programming: which release of HuC / MKit to use???

Has anyone tried assembling their own .ASM program with "HUC" not defined anywhere, recently?

I'm trying to get a nice, most-recent version of HuC/PCEAS to assemble my own short test .asm files, but it's driving me crazy.  For my own ASM projects, I had always used some rather old versions of PCEAS from MagicKit, simply because the libraries were short and simple.

For the tutorial videos, I thought I ought to let beginners start at an up-to-date version of HuC & use the PCEAS portion of it only-- so that if they decided they wanted to switch to HuC, they could -- ..., only to find tons of errors.

Perhaps someone here can help.

In both HuC 3.21 and 3.22 (Artemio's) if I supply a very short .ASM file with a .include "STARTUP.ASM", it gives tons of errors (.bank DATA_BANK,"User Program" Different bank names not allowed! ) , ( __ldw     <_ax Unknown instruction! ) eg.
If I actually define HUC, it gives a different raft of errors.

Any known way out of this morass?  Should I just stick with the oldest MagicKit?

[Bonknuts]

Or, just not use any of the libraries with any of them. I've never used any those libraries from Mkit. And definitely not anything from HuC (startup.asm, etc) for ASM stuff. Not for the reasons you listed, but I think I do remember running into some of the same stuff as you are - in that I didn't care to sort out.. at one time (was doing it for someone else, I think).

 You can still use the built in sprite, tile, and bat directives/import features without needing Mkit map routines. It's not like the PCE hardware is some convoluted design; it's clean and easy to understand, so writing your own code to show off stuffs should be easily to follow. My personal philosophy; every assembly programmer should have to learn how to write their own map routines from scratch before using anyone elses libs.

 If you want a very basic library to include with your examples, I could always adapt the stuff that I use (startup routine that initializes hardware, sets up banks, jumps to main. A set of macros, print routines, etc).

 Or maybe this is a better question: what is it exactly that you need from huc lib or Mkit lib?

[ccovell]

Abandoning the MKit libraries going forward is not a good idea, 'cause:

1) While I don't expect to use HuC or the...er... larger library functions, I also don't want to force PCE ASM beginners to ride bareback, either.

2) It means the MagicKit libraries become mere support functions for HuC only, rather than things to support actual humans who might use the other, also useful, half of the HuC package.

[Bonknuts]

It would just be easier to make a custom lib from HuC/Mkit library.

 What exactly do you need from those libraries, though?

[elmer]

SHORT: ASM-only programming: which release of HuC / MKit to use???

Has anyone tried assembling their own .ASM program with "HUC" not defined anywhere, recently?

When I tried this last year, I just gave up. The mess of nested includes was too horrible to deal with.

I can't see why-on-earth you'd want to lock new assembly-language programmers into the horrors that are in startup.asm.

Because of all the stuff that's in there, it's just plain *nasty* trying to wade through the listing file output of a HuC project to see where you own assembly code actually is.

IMHO, if you want to make things "easy" for folks, just target the SCD with all of the built-in System Card stuff to make things simpler for people.

Both Bonknuts and I posted simple ASM skeletons (that don't pull in huge chunks of HuC) in the "Getting started programming?" thread.

You can still use the built in sprite, tile, and bat directives/import features without needing Mkit map routines. It's not like the PCE hardware is some convoluted design; it's clean and easy to understand, so writing your own code to show off stuffs should be easily to follow. My personal philosophy; every assembly programmer should have to learn how to write their own map routines from scratch before using anyone elses libs.

This. Really. This.

Another alternative is to extract your own "beginner" set of simple functions from the libraries.

Again ... if you base things on the SCD rather than the bare HuCard system, you get a whole lot of basic functionality built into the System Card, so that you can just focus on the simple flow of your lessons.

If you were using the System Card environment for the guts of the lessons, then you probably wouldn't even need much from the MKit libraries.

Abandoning the MKit libraries going forward is not a good idea, 'cause:

You are more-than-welcome to get onto github and start generating some pull-requests that clean things up a bit so that people can actually write assembly-only projects with the current tools. 

[ccovell]

Hmm... OK, food for thought.  My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn.  Just jump right in and learn how to write things to regs...   I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...

But at the same time I did want the viewer to download 1 thing (HuC) and start up a command prompt and type PCEAS and/or be able to switch to a higher/more complex thing (HuC w/ libs or PCEAS w/ libs) if they wanted to.  At this point, the latter is not possible.

[nodtveidt]

My attempts at writing assembly-only programs with pceas (Denki version) could not succeed at all without the default libraries, at which point it seemed fruitless to even bother trying. You either use the libraries and gain very little advantage over clean HuC code, or start from nothing and attempt to lift mountains. Didn't seem to be any in-between without already being an expert in assembly.

[Bonknuts]

Hmm... OK, food for thought.  My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn.  Just jump right in and learn how to write things to regs...   I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...

 Well.. take the startup routine for PCE for example: set high speed cpu mode, set stack pointer, clear ram, disable interrupts, a block of reg stuff copied to the VDC (no need to go over individually each part yet of the regs). Maybe something for the sound, map in a couple of banks. That's your basic startup. 

 To me, stuff like this is part of what beginners should be learning. Simply because, there isn't a nice complete set of libs out there for the system. And learning the basics makes them free'er than lib dependency. Can help with problem solving in the future too.

 But you could make something, where they could reuse it for experimenting beyond or in between your tutorials (have links to downloadable stuff). A basic startup routine would be a good starting point.

But at the same time I did want the viewer to download 1 thing (HuC) and start up a command prompt and type PCEAS and/or be able to switch to a higher/more complex thing (HuC w/ libs or PCEAS w/ libs) if they wanted to.  At this point, the latter is not possible.

Maybe break it off into tutorials for assembly, and a separate one for HuC?

My attempts at writing assembly-only programs with pceas (Denki version) could not succeed at all without the default libraries, at which point it seemed fruitless to even bother trying. You either use the libraries and gain very little advantage over clean HuC code, or start from nothing and attempt to lift mountains. Didn't seem to be any in-between without already being an expert in assembly.

 Yeah, but if there were tutorials to show how to do all the basics, the learning curve would be that much more shortened. I'm definitely not against showing how to do tilemap routines from scratch; the exact opposite.

 But it's that assembly is a specific type of environment and expectations. I've always argued that learning processor assembly is the easy part - it's learning how to use and understand all the surrounding hardware on the same low level that's the challenge. I was no expert in assembly back in 2005, even if I had some previous experience with ASM on PC and gameboy color. It took me a year to get pretty comfortable on the PCE. A year of dabbling here and there.



 Ccovell: If you do plan to write some simple tilemap routines from scratch, and want to use Mappy - I have a commanline conversion tool you can use. I've not made it public, but I don't mind distributing it for tutorials (include it directly, if you need to).

Code: [Select]

FMP to PCE map converter. Ver 1.0.6-a
 -Usage: fmp2pce <source.ext> -option
  -o<n>      <n> is the subpalette offset for the tilemap. 1 digit hex
  -l<n>      <n> is the length of output palette block; (n+1)*16. 1 digit hex
  -v<n>      Tile offset in vram (kWORDs). 3 digit hex. Default is 100h
  -s         Output the tile map in vertical strips instead of horizontal
  -c<n>      Output byte-wide collision map for <n> layer.
  -e         Use embedded color encoding to build palette map data in tilemap
  -x1<n>     Clip map: horiztonal start position. Value must be a 4digit hex
  -y1<n>     Clip map: vertical start position. Value must be a 4digit hex
  -x2<n>     Clip map: horiztonal end position. Value must be a 4digit hex
  -y2<n>     Clip map: vertical end position. Value must be a 4digit hex
  -m16       Convert 16x16 map for 'no LUT' expansion.
  -m8        Convert 16x16 map into 8x8 map. (TO DO)
  -to<n>     Offset collision tile # (tile# - n, saturated floor at 0x00/0x01).
             ^-Note: <n> is 3 digit hex max. Large values create 0/1 maps.
  -z<name>    Up to 10digits. Results in <name>.ext for file outputs.

 '14 Tomaitheous
I remember HuC having FMP support, but I don't remember it in PCEAS. Either way, I needed more options.

[dshadoff]

Hmm... OK, food for thought.  My vague idea for the videos had been to stay close to the hardware and thus not rely on functions, libraries, or a whole book of things to learn.  Just jump right in and learn how to write things to regs...   I guess it might make sense to start out with nothing and write my/our (meaning the viewer) own startup libraries...

 Well.. take the startup routine for PCE for example: set high speed cpu mode, set stack pointer, clear ram, disable interrupts, a block of reg stuff copied to the VDC (no need to go over individually each part yet of the regs). Maybe something for the sound, map in a couple of banks. That's your basic startup. 

 To me, stuff like this is part of what beginners should be learning. Simply because, there isn't a nice complete set of libs out there for the system. And learning the basics makes them free'er than lib dependency. Can help with problem solving in the future too.

Well, I'm sure that people will have various opinions on whether I was successful or not, but...

This is exactly what I was trying to convey when I wrote and profusely commented the HuC libraries:

1) initialization sequence - what is required, and why you would want to do any of those things
2) some notes about the hardware, to build famliarity - because documentation on even the hardware itself is/was scarce
3) some standard ways of accessing the hardware, which work - so that you don't have to reinvent the wheel.  Mix and match is you like.
4) some notes on a way to manage memory banks (pin one, assign "jobs" to the others for simplicity (i.e. paged code, paged data, hardware, etc.), and page them in/out as needed).

None of the above would be even close to obvious to somebody who hasn't worked on another contemporaneous paged-memory, hardware-mapped I/O system.  And this is usually where people still find fault... while the code works and is commented (two things which aren't true of most business systems I have had to fix for my day job), it still isn't obvious enough for most people.

This is why my first response to everybody who wants to use assembler on the PCE has always been to start by examining the HuC libraries.  Not because they're perfect in any stretch - but because they convey necessary information.  In building them, I had to learn the hard way what was necessary (and why), and it was my way of sharing that hard-fought knowledge.


Having said that, I'm sure that videos would be helpful, because you can take a minute or two to explain *why* something is the way it is - whereas writing the same thing may take 30 minutes, and still not convey it well enough.

-Dave

[ccovell]

Please, experts, give all your input (Like Dave, Tom, Elmer have) because I'm not one yet.

If you think of HuC as "PCE 101" in college, then I think ASM using the libraries to help you would be "PCE 201", and without libraries would be "PCE 220", if not a postgraduate course :-)

Although starting with setting up the system / banks / etc is a good idea, even for beginners to the PCE, I think some preexisting helper libraries are needed for the beginner after the basic HW init is done.