Phactory problem

[ervin]

Hi all.
 
I've downloaded norecess' Phactory, and from what I've seen so far, it is really good!
Could really help productivity.
 
However, I've hit a problem right at the start.
 
I've created a little asm program as per norecess' instructions. It looks like this:
 

Code: [Select]

org &4000
 
ld a,65
call &bb5a
 
ld a,66
call &bb5a
 
ld a,67
call &bb5a
 
ret
When I build it, Phactory opens winape and runs the program.
As expected, it prints "ABC" on the screen.
 
However, it performs a cls first, which I didn't want, and it resets winape after printing ABC.
 
Does anyone know what might be wrong?
Has anyone else had a go with Phactory?
 

[SuTeKH/Epyteor]

When I build it, Phactory opens winape and runs the program.
As expected, it prints "ABC" on the screen.
 
However, it performs a cls first, which I didn't want, and it resets winape after printing ABC.
 
Does anyone know what might be wrong?
Has anyone else had a go with Phactory?

This isn't PHACTORY's fault. Try creating an executable file with your 'ABC' program, you'll see that it does exactly the same.
I've attached a little .dsk to show you.
 
RUN"ABC.BAS" acts as if you've assembled the data in ASSEM, then CALLed as normal.
RUN"ABC.BIN" runs an executable M/C file, which is what PHACTORY is doing. (tested on JavaCPC and WinAPE)
 
EDIT: Executable BINARY files do not resolve to BASIC. If you want it to work in your projects and resolve back to a BASIC prompt, you will need to create a BASIC loader program first... or there's probably some code you need to add to do so; someone more knowledgable will be able to provide sources.

[ervin]

Good lord, I am such a dumba$$.

That's exactly what I've been doing to run my Chunky Pixel Collision code that I've been writing using ccz80.
Why on earth I didn't realise that I'd need a BASIC loaded program is beyond me... geez.

Thanks for your quick reply - I can now get back to trying out Phactory.
If I don't have too much trouble learning C, I might convert chunky pixel collision to it as a test.

[SuTeKH/Epyteor]

Good lord, I am such a dumba$$.

Not really; sometimes a genius mind will overlook the easy things while trying to solve the hardest of problems.

[ervin]

Yeah, I'll go with that! 

[AMSDOS]

If you wanted to go all fancy you could make one of those BASIC stub files which call's the routine in question followed by END to return to BASIC. The routine that could be called could be something which shifts the relevant program to the right spot in memory and then called, followed by a RET after that which returns you to the END bit!    Saves having the extra loader file. On the later Covertapes, AA used these for their Menu's which was quite clever! 

[ervin]

Interesting idea... might have to consider that one.

[TFM]

I'm just glad, that I don't have that kind of problems any longer. I start binaries directly the way I like it

[AMSDOS]

Interesting idea... might have to consider that one.

There's a small article about it here. I think the other advantage of it is how it adds to the presentation of your program, though it works best once you've added the final touches to your program.
 
Disadvantages: I did this whole menu thing with graphics, colourful mode 1 text, threw on top of that a game of Harrier Attack so it was built-into that program, saved it (using a routine Firmware saving routine which saves as a BASIC file, with the set start address & length), which all worked out wonderful, except one problem. I forgot to put a MODE 1 at the start of my program!! I was horrified and I couldn't do anything about it, couldn't add MODE 1 to that program and couldn't add it in my routines!    Though I've still got the file and I think I've got it on one of my Disk Images! 

[SuTeKH/Epyteor]

Disadvantages: I did this whole menu thing with graphics, colourful mode 1 text, threw on top of that a game of Harrier Attack so it was built-into that program, saved it (using a routine Firmware saving routine which saves as a BASIC file, with the set start address & length), which all worked out wonderful, except one problem. I forgot to put a MODE 1 at the start of my program!! I was horrified and I couldn't do anything about it, couldn't add MODE 1 to that program and couldn't add it in my routines!    Though I've still got the file and I think I've got it on one of my Disk Images! 

That article says that you can start your M/C program as low as &17C, but I'd recommend starting at &180. This is so you can add any 'emergency' commands to your BASIC 'loader'.
 
I came up with this while messing around with Devilmarkus's overscanned pictures via JavaCPC a while back;

Code: [Select]


0170 0E 00 0A 00 AD 20 0F 01
0178 83 20 1C 80 01 00 00 00
0180 --> Your program here!

The above code is BASICally; (see what I did there?)

Code: [Select]


10 MODE 1:CALL &180

0F at address &0176 denotes the MODE number; in this example MODE 1. For MODE 0, change it to 0E and for MODE 2 change it to 10.
 
@CPM/User
Where does your code start for this menu program? If it's beyond &17D, then it could be possible to insert the MODE 1 command before the CALL... and, from experience, all you would need to do is a basic SAVE command to save all changes. (ie without all that messy fiddling with BC7A and all in MAXAM)

[AMSDOS]

That article says that you can start your M/C program as low as &17C, but I'd recommend starting at &180. This is so you can add any 'emergency' commands to your BASIC 'loader'.
 
I came up with this while messing around with Devilmarkus's overscanned pictures via JavaCPC a while back;

Code: [Select]


0170 0E 00 0A 00 AD 20 0F 01
0178 83 20 1C 80 01 00 00 00
0180 --> Your program here!

The above code is BASICally; (see what I did there?)

Code: [Select]


10 MODE 1:CALL &180

0F at address &0176 denotes the MODE number; in this example MODE 1. For MODE 0, change it to 0E and for MODE 2 change it to 10.
 
@CPM/User
Where does your code start for this menu program? If it's beyond &17D, then it could be possible to insert the MODE 1 command before the CALL... and, from experience, all you would need to do is a basic SAVE command to save all changes. (ie without all that messy fiddling with BC7A and all in MAXAM)

This particular menu program I came up at the time is a combination of BASIC menu, selection and execution of program along with a compressed screen (which is displayed as soon as the Menu is running). Fortunately there is one line which could be used for the MODE 1, I just need to make sure it is equal length to the original line, otherwise everything else moves in the code, I think I can resolve this with some &20s which should be space.

[SuTeKH/Epyteor]

I just need to make sure it is equal length to the original line, otherwise everything else moves in the code, I think I can resolve this with some &20s which should be space.

I don't believe changing BASIC 'code' will be as easy as adding spaces to lines and may need a lot of experimentation (but don't quote me). I would suggest adding NOPs (&00) to the very end of the BASIC 'code' instead (ie, before the z80 code kicks in) or possibly trying to stream-line your BASIC in some way; using single character variables instead of long words, removing duplicate routines and calling a single routine via GOSUB/RETURN, removing any REMs or unwanted commands, etc.
 
I'd be interested to see this menu system and your results once completed; if you would wish to share it with us. I always like to see people using BASIC instead of all this messy assembler nonsense; it's far overrated in my view*.
 
 
(* But that's possibly because I can't program in assember, but that's a different story)

[AMSDOS]

I don't believe changing BASIC 'code' will be as easy as adding spaces to lines and may need a lot of experimentation (but don't quote me). I would suggest adding NOPs (&00) to the very end of the BASIC 'code' instead (ie, before the z80 code kicks in) or possibly trying to stream-line your BASIC in some way; using single character variables instead of long words, removing duplicate routines and calling a single routine via GOSUB/RETURN, removing any REMs or unwanted commands, etc.
 
I'd be interested to see this menu system and your results once completed; if you would wish to share it with us. I always like to see people using BASIC instead of all this messy assembler nonsense; it's far overrated in my view*.
 
 
(* But that's possibly because I can't program in assember, but that's a different story)

And I thought Assembly was all you knew or did! 
 
I found some extra bytes which allowed me to slip in some M/C to Setup the Screen Mode, I've attached the Off-Topic Profanity with the Menu (isn't all that earth shattering)!

[SuTeKH/Epyteor]

And I thought Assembly was all you knew or did! 

God, no! Just ask any of the assembler Gods here!
I love BASIC and FIRMWARE!
 

I found some extra bytes which allowed me to slip in some M/C to Setup the Screen Mode, I've attached the Off-Topic Profanity with the Menu (isn't all that earth shattering)!

It looks like you've got another 20 bytes spare before your LD A,1/CALL &BC0E to add any required code to.
 
I have one question, though; what does the FOR red = 0 TO 0 loop do at the beginning of the code? It seems redundant to me, but I may be missing something technical.
 
If you exomized these AMSOFT games, you could get a (or THE) whole collection singled-filed. Change to z80 code for the menu and have a bunch of packed game-files in succession. LDIR the required pack file to C000-FFFF, then de-exo to the required address and JP to the start of the game.
You could tag it to a &170 BASIC loader or executable BINARY file from &100 onwards. I reckon you might be looking at 20-25 games per 44k file! Easy! And 4 of these files per .dsk! Maybe 100 games on one AMSDOS disk! Wow!
 

[AMSDOS]

It looks like you've got another 20 bytes spare before your LD A,1/CALL &BC0E to add any required code to.

Heh yeah, to me I played it safe and had like 16 bytes free between one bit of code to another, it was pretty much moved into that place.
 

I have one question, though; what does the FOR red = 0 TO 0 loop do at the beginning of the code? It seems redundant to me, but I may be missing something technical.

Yeah, don't expect meaningful code from me from back in them days    I was still busy being a punk teenager hacking games and writing Menu's for them, they worked and then I'd move onto more games and more Menu's instead of acting like a normal teenager would!   
Though from that I can pretty much tell that I would of copied that bit of code from somewhere else (from a magazine), though it's funny cause I cannot seem to find the program in question (possibly from AA). That FOR loop specifically would have come into play if there was more DATA lines to be POKEd in. There isn't so yes that particular loop isn't required!    Beyond that it reads the contents of the DATA into a$ which is all of that M/C routine, the second FOR loops that DATA in until the length of a$ has been reached.
 

If you exomized these AMSOFT games, you could get a (or THE) whole collection singled-filed. Change to z80 code for the menu and have a bunch of packed game-files in succession. LDIR the required pack file to C000-FFFF, then de-exo to the required address and JP to the start of the game.
You could tag it to a &170 BASIC loader or executable BINARY file from &100 onwards. I reckon you might be looking at 20-25 games per 44k file! Easy! And 4 of these files per .dsk! Maybe 100 games on one AMSDOS disk! Wow!

You mean Compress into main memory, uncompress to screen and then move that code to where it goes into memory. I did have an idea like that at one stage and that maybe the reason why there's a few AMSOFT games on that Disk Image. Some AMSOFT games are too big in some sense to do that, though your smaller games 16k and under would certainally work!    Unfortunately I've sort of moved on a little bit from them days trying to make bigger things!    Though they were fun to make your own little Menu's up, these days I'd probably resort to using my own little drawing routines which would produce screens like what you'd have on the Menu screen which might perhaps cut the length of it slightly, though them compressed screens were fairly well compressed! 

[SuTeKH/Epyteor]

You mean Compress into main memory, uncompress to screen and then move that code to where it goes into memory. I did have an idea like that at one stage and that maybe the reason why there's a few AMSOFT games on that Disk Image. Some AMSOFT games are too big in some sense to do that, though your smaller games 16k and under would certainally work!

Not quite. I mean have a stack of packed data from, I dunno, &0500-&A500. Let the user pick a game, then LDIR whichever packed data-chunk is meant for that game to &C000 (the screen, which will need to be blanked first) and then decompress from &C000 to whatever address the game starts at. Finally, JP to the game's start address.
 
For example, the three games on that disc (ASTRO.BIN, BACK1.BIN, HAUNTED.BIN) take up just under 40k of space (3E80, 3A98, 2B18 bytes respectively), yet when compressed they only take up around 16k (15D1, 14B0, 13D1). So, it would be easy to have 7 or 8 games 'stacked up' per 40k file.

[AMSDOS]

Not quite. I mean have a stack of packed data from, I dunno, &0500-&A500. Let the user pick a game, then LDIR whichever packed data-chunk is meant for that game to &C000 (the screen, which will need to be blanked first) and then decompress from &C000 to whatever address the game starts at. Finally, JP to the game's start address.
 
For example, the three games on that disc (ASTRO.BIN, BACK1.BIN, HAUNTED.BIN) take up just under 40k of space (3E80, 3A98, 2B18 bytes respectively), yet when compressed they only take up around 16k (15D1, 14B0, 13D1). So, it would be easy to have 7 or 8 games 'stacked up' per 40k file.

Don't know about 7 or 8 games, depends on how good the compression is I suppose. The program I had in mind (SQ), is essentually a screen compressor so decompresses to screen and from there the program can be moved into it's proper place!    The big plus with that program though is the compressed information can literally be called from anywhere in main memory (my menu is calling that screen from around &0400, though I think you can go even down to &0180 and possibly lower if you doing it in M/C, unsure though).
Other compressors probably do have some benefits compared with Screen Compressors though, I'm not sure though. Screen Compressors tend to look into patterns and re-occurring values though, so may have disadvantages over a Binary Compressor.

[SuTeKH/Epyteor]

Don't know about 7 or 8 games, depends on how good the compression is I suppose. The program I had in mind (SQ), is essentually a screen compressor so decompresses to screen and from there the program can be moved into it's proper place!    The big plus with that program though is the compressed information can literally be called from anywhere in main memory (my menu is calling that screen from around &0400, though I think you can go even down to &0180 and possibly lower if you doing it in M/C, unsure though).
Other compressors probably do have some benefits compared with Screen Compressors though, I'm not sure though. Screen Compressors tend to look into patterns and re-occurring values though, so may have disadvantages over a Binary Compressor.

I used exomizer on PC to compress the three games and WinAPE to transfer files between PC and CPC environments. The Z80 decompressor source code is supplied on the exomizer .dsk and will only require a few LDIR commands to move each 'pack' in memory. Due to their size, maybe using VRAM is a little over-enthusiastic and they could very well be happy enough sitting from &0080 onwards!

[TotO]

I'm trying Phactory with C language, but I got this error:

------ Build started: Test2 ------

Compiling...
main.c
Compilation failed with 'main.asm'..
Log output:
ERROR on line 44 of file C:\Documents and Settings\Administrateur\Bureau\Test2\Resources\main.asm
ERROR: Symbol '_printf' is undefined
Build failed !

Here my simple "C code" test:

Code: [Select]

#include <stdio.h>


void main()
{
   unsigned int i;


   for(i=0;i<65535;i++)
   {
      printf("hello world!\n");
   }
}

If you can help me ? (stdio.h exist in the SDCC include directory)
Thank you.

[TFM]

Try SDCC alone, do you get the same error?
 

[ervin]

Hi all.
 
Alrighty, I give up.
I just can't figure out how to put a BASIC stub into a BIN file, and I have no idea how to get an actual BAS file into Phactory.
 
Can anyone help me?
I'm at wits end with this.
 
All I want to do is run this simple code correctly.
 

Code: [Select]


org &0200
ld a,65
call &bb5a
ld a,66
call &bb5a
ld a,67
call &bb5a
ld a,68
call &bb5a
ret


[AMSDOS]

Hi all.
 
Alrighty, I give up.
I just can't figure out how to put a BASIC stub into a BIN file, and I have no idea how to get an actual BAS file into Phactory.
 
Can anyone help me?
I'm at wits end with this.
 
All I want to do is run this simple code correctly.
 

Code: [Select]


org &0200
ld a,65
call &bb5a
ld a,66
call &bb5a
ld a,67
call &bb5a
ld a,68
call &bb5a
ret


I use a Monitor program, one that can Dissassemble, Memory Edit (with Hexidecimal and ASCII Input). From that I write a small routine to save the stub file:



From that moving down that small routine the 'B' register holds the length of the Filename (which must include the ".BAS" extension, so upto 12 characters), HL points to the start address of the filename, DE which I've put &170 in it is a Buffer which probably should be anywhere else (as long as 2k is allowed!  ), &BC8C which opens up an output file. Following that HL is where the program begins, &170 being BASIC, the Length which goes into DE, I use a Monitor program to get the end address and subtract &170 from that to get the length, A holds the type of file it is, 0 for BASIC, &BC98 writes the file to Tape or Disc and &BC8F closes the output file, no entry conditions required for &BC8F.
 
I've attached this image to show how the M/C would come up with the stub file in the Memory Lister, as you can see there's a bit of room between where the BASIC stub file begins and ends and the M/C.


 
I think to get a Phactory program working from a BASIC stub file, you would setup a BASIC file:
 

Code: [Select]

10 call &200 ' or whatever
20 end
At &200 or instance you may have this:
 

Code: [Select]


ld hl, <where the phactory program is>
ld de,<where the phactory program needs to go>
ld bc,<size of it>
ldir
jp <where the phactory program is>
ret

So if you have a Binary file done in Phactory, a really good Monitor program like Lara can load it in place tell you the information like where it begins the length of it and an execution address which goes into that routine above which your BASIC stub bit is calling! 

[SuTeKH/Epyteor]

@ervin
Here's a little M/C routine that you can use to inject your M/Code into BASIC. It calculates everything for you.
All you need to do is stick the M/Code routine where shown and then CALL &A000. The .BAS file is created for you.

Code: [Select]


ORG &170
 
.BASIC_Start
DEFB &0A,&00,&0A,&00,&83,&20,&1C,&00 ; 10 CALL &200
DEFB &02,&00,&00,&00,&00,&00,&00,&00
 
; Insert M/Code routine or Phactory code here!
; For now, here's your ABCD example
ORG &0200
LD A,65
CALL &BB5A
LD A,66
CALL &BB5A
LD A,67
CALL &BB5A
LD A,68
CALL &BB5A
RET

; This line needs to be left in!
.BASIC_End
 
; This calculates the overall size of the 'BASIC' file (ie, BASIC & M/C together)
.BASIC_Length equ BASIC_End-BASIC_Start

; BASIC file SAVE routine
ORG &A000
LD B,Filename_Length
LD HL,Filename_Start
LD DE,&0000
CALL &BC8C
LD HL,&0170
LD DE,BASIC_Length
LD BC,&0000
LD A,0
CALL &BC98
CALL &BC8F
RET

; Filename can be anything you want! The code auto calculates filename length.
.Filename_Start
defm "BASIC.BAS"
.Filename_End
 
.Filename_Length equ Filename_End-Filename_Start

NOTE: Do not edit the BASIC 'listing' (ie, 10 CALL &200) as it will shift the M/Code routine up a number of memory locations! This could be fatal if you're CALLing or JPing to specific locations!
Also, If you want to CALL another location (rather than &200) then change the last byte of the first line and the first byte of the second line of 'BASIC' data!

[Devilmarkus]

@ervin
Here's a little M/C routine that you can use to inject your M/Code into BASIC. It calculates everything for you.
All you need to do is stick the M/Code routine where shown and then CALL &A000. The .BAS file is created for you.

Code: [Select]


ORG &170
 
.BASIC_Start
DEFB &0A,&00,&0A,&00,&83,&20,&1C,&00 ; 10 CALL &200
DEFB &02,&00,&00,&00,&00,&00,&00,&00
 


Don't forget to manipulate the AMSDOS header later, when the file is saved, otherwise it will not start!
Change it from binary to basic.
It's located at offset 18 in the file.
    type:
     * 0 = BASIC
     * 1 = BASIC (prot.)
     * 2 = BINARY
     * 3 = BINARY (prot.)
     * 4 = IMAGE
     * 5 = IMAGE (prot.)
     * 6 = ASCII
     * 7 = ASCII (prot.)

(JavaCPC automatically writes the BASIC flag, when you store it with fileextension .bas, e.g.: write "DISK.BAS" )

[SuTeKH/Epyteor]

Don't forget to manipulate the AMSDOS header later, when the file is saved, otherwise it will not start!
Change it from binary to basic.
It's located at offset 18 in the file.
    type:
     * 0 = BASIC
     * 1 = BASIC (prot.)
     * 2 = BINARY
     * 3 = BINARY (prot.)
     * 4 = IMAGE
     * 5 = IMAGE (prot.)
     * 6 = ASCII
     * 7 = ASCII (prot.)

Do you mean this part of the program?

Code: [Select]


LD HL,&0170
LD DE,BASIC_Length
LD BC,&0000
LD A,0            <----- AMSDOS file type 0 - BASIC
CALL &BC98
CALL &BC8F

 
EDIT: Damn it! Why didn't I use XOR A instead of LD A,0? Ah well, doesn't matter in such a small program, I guess.