pasmo weirdness

[Nomad]

I would suggest you document your mistake in this thread (if it's not too embarrassing ), since it might be useful for someone else that might be doing the same mistake in the future.

Yes that is a good idea

So what the problem was - before when creating the taps in pasmo it generated a basic loader.
Now that does not seem to be happening. So I was expecting pasmo to have handled the basic commands that in the end i had to enter in manually, as a program. When i tried to do it 'interactive' at the basic prompt it would not work.

Much like roshack and Einar said - but the issue was I was trying to do the sequence without line numbers.

Code: Select all

10 CLEAR 49999 
20 RANDOMIZE USR 50000
30 LOAD "" CODE
RUN

line 10 needs to be n-1 where n is your ORG number.
line 20 needs to be the ORG number

After I RUN, the value of HL in the debugger is what it should be.

I did this in Fuse.

[Seven.FFF]

Did you have the END directive at the end of the source?

[Nomad]

Did you have the END directive at the end of the source?

No perhaps that was it, I tried it with END before but it was the same result. I'll give it another go.. I am sure it had the functionality before and there was some cyrptic requirement for pasmo to have an END statement linked to the ORG or the main label right I will check that later as it sounds like this is the problem.

Weird thing is pasmo just happy creates the tap without letting on the END is missing.

[Seven.FFF]

END is nothing to do with ORG. There’s a single END, at the end, to tell it how to create the loader. It’s something specific to pasmo and it’s loader generation.

ORGs are scattered all round your source, and tell the assembler what address to lay down the next assembled bytes at that point in the source code. There’s no requirement to have any ORGs at all, in which case assembly starts at $0000, which is often RAM in older Z80 systems. ORG as a concept is pretty general to most assemblers, although it occasionally uses a different directive.

[Nomad]

I Tried END SC6A didn't seem to work
same with the ORG number END..

same with END at the end of SC6A listing.

First attempt with the END 50000 - this used to work with my other programs in pasmo.

Code: Select all

ORG 50000

SC6A:
		LD		HL,-2			; HL = MULTIPLICAND
		LD		DE,1023			; DE = MULTIPLIER
		CALL	MUL16			; 16-BIT MULTIPLY
								; RESULT OF 1023 * -2 = 0F802H
								;  REGISTER L = 02H
								;  			H = F8H
		JR		SC6A
		
INCLUDE "MUL16.ASM"

END 50000

Then I tried ending with the END SC6A as that was the main program label..

Code: Select all

ORG 50000

SC6A:
		LD		HL,-2			; HL = MULTIPLICAND
		LD		DE,1023			; DE = MULTIPLIER
		CALL	MUL16			; 16-BIT MULTIPLY
								; RESULT OF 1023 * -2 = 0F802H
								;  REGISTER L = 02H
								;  			H = F8H
		JR		SC6A
		
INCLUDE "MUL16.ASM"

END SC6A

Finally I tried just a simple END

Code: Select all

ORG 50000

SC6A:
		LD		HL,-2			; HL = MULTIPLICAND
		LD		DE,1023			; DE = MULTIPLIER
		CALL	MUL16			; 16-BIT MULTIPLY
								; RESULT OF 1023 * -2 = 0F802H
								;  REGISTER L = 02H
								;  			H = F8H
		JR		SC6A
		
INCLUDE "MUL16.ASM"

END 

Like I might be taking crazy pills but what is the point of using the tap generator over the binary blob if pasmo can't generate a working basic loader stub

[Seven.FFF]

It’s not such a great assembler. it’s old, largely abandoned, easily confused and doesn’t always do what the documentation says it does. I lose patience with it pretty easily!

[Nomad]

END is nothing to do with ORG. There’s a single END, at the end, to tell it how to create the loader. It’s something specific to pasmo and it’s loader generation.

ORGs are scattered all round your source, and tell the assembler what address to lay down the next assembled bytes at that point in the source code. There’s no requirement to have any ORGs at all, in which case assembly starts at $0000, which is often RAM in older Z80 systems. ORG as a concept is pretty general to most assemblers, although it occasionally uses a different directive.

Yes I remember the Lance A main book uses ORG 00000 as the load location for the programs. I think that is what it is on the S100 Bus systems.

It’s not such a great assembler. it’s old, largely abandoned, easily confused and doesn’t always do what the documentation says it does. I lose patience with it pretty easily!

Words can't adequately state how salty pasmo made me last night Im a hot potato right now.

There is a little voice that is constantly whispering 'you should have use zeus you potato..."

I checked out the website and there is an entire demonstration on how 128k memory paging works and how to use it. Kudos Simon..

http://www.desdes.com/products/oldfiles ... x_v352.asm

I forgotten why I don't use the zeus IDE lol - it looks terible with wine, all the windows are out of wack.

I guess its alright for just testing the monitor but its totally unusable as an every day ide.

how difficult would it be to get a linux version of zeus? not using some crippled wine hack?



Would you use a application that did this?

So I end up with a choice between a assembler that can't assemble a simple tap (pasmo). or an IDE that looks like aids on my screen (zeus).

Lol... so much fail with the spectrum stuff...

It does not have to be this way... if you want to develop on atari 800 you can use an emulator that has only been under constant development since 2009 (instead of the decades long development cycles of the spectrum stuff...) but unlike the spectrum junk this actually works exactly like the hardware, is usable and you don't need special hacks/manuals just to use the emulators. Just the original documents for the original hardware, software.

Perhaps the spectrum is a much harder platform to emulate properly? I can't explain why they fail so hard compared to the Atari 800 stuff.













This runs out of the box under wine, everything functions fine.



Don't mind me I am just extra salty today.

[AndyC]

It does not have to be this way... if you want to develop on atari 800 you can use an emulator that has only been under constant development since 2009 (instead of the decades long development cycles of the spectrum stuff...) but unlike the spectrum junk this actually works exactly like the hardware, is usable and you don't need special hacks/manuals just to use the emulators. Just the original documents for the original hardware, software.

Perhaps the spectrum is a much harder platform to emulate properly? I can't explain why they fail so hard compared to the Atari 800 stuff.

I think it's more of a "real world" constraint in this case. Almost no Spectrum users had disc drives and microdrives were a bit niche too, so pretty much everything has to work with tape. An "on machine" assembler, therefore, was pretty much going to have to store the assembly source code and final object code in memory, which with only 48K is a bit limiting. Plus you have to save out all your code to tape (takes ages), run it, have the machine crash, reload the assembler (ages), reload the source (more ages) and so on. It always made learning to program on the spectrum a much more painful task without the benefits of a cross assembler.

In contrast, on the CPC I wrote my own assembler in BASIC that read a source file on disc and assembled the binary to a file on disc. Even being written in BASIC (and still having to load a separate disc based text editor) this was light years faster and more productive. Moving beyond that to ROM based tools (Protext + Maxam being the gold star toolset) was like having a modern IDE in terms of how quickly you could turn things around. I've not tried coding on the Atari, but I'd imagine it's not a dissimilar experience.

[Einar Saukas]

Code: Select all

10 CLEAR 49999 
20 RANDOMIZE USR 50000
30 LOAD "" CODE
RUN

Lines 20 and 30 must be swapped. You were trying to execute the code before loading it.

[Seven.FFF]

Zeus looks fine, except you have the fonts set too large. What is it you don't like, the Toggle Code pane?

[Nomad]

Zeus looks fine, except you have the fonts set too large. What is it you don't like, the Toggle Code pane?

what I want to do is move the code window so it uses the unused space to the left. I think the font issue is down to the wineconfig I will have a play with it. on default you get size 4-5 fonts that can't really be altered in the application menu for some stuff (that requires ms default fonts)

Right clicking i can kill some of the menu dead space but it still looks terrible - like a windows 3.1 application Even this would be ok but the menus themselves seem broken in many places.

I guess only other irritation with zeus is all of the boiler plate stuff - one thing I like a lot is the monitor - debugger is good also. There are probably a bunch of obscure boilerplate stuff I need to do to the code to get it to even run on zeus. That is probably why the HL value is not showing the correct value.

I just reset wine's configs for zeus back to default. a lot of the menus are still broken. It also does not seem to run the program - when i assemble and run the program it just keeps cycling through a bunch of values in HL none of which are the ones the example program says should be in HL..

[Seven.FFF]

The unused space to the left shows the address and first eight assembled bytes for each line of source code. You have to click Assemble for it to show though.

It’s highly possible I suggested you to show the pane when you were having probs with visualising what was being assembled! You can hide it again with right click > toggle code.

[Nomad]

I think it's more of a "real world" constraint in this case. Almost no Spectrum users had disc drives and microdrives were a bit niche too, so pretty much everything has to work with tape. An "on machine" assembler, therefore, was pretty much going to have to store the assembly source code and final object code in memory, which with only 48K is a bit limiting. Plus you have to save out all your code to tape (takes ages), run it, have the machine crash, reload the assembler (ages), reload the source (more ages) and so on. It always made learning to program on the spectrum a much more painful task without the benefits of a cross assembler.

In contrast, on the CPC I wrote my own assembler in BASIC that read a source file on disc and assembled the binary to a file on disc. Even being written in BASIC (and still having to load a separate disc based text editor) this was light years faster and more productive. Moving beyond that to ROM based tools (Protext + Maxam being the gold star toolset) was like having a modern IDE in terms of how quickly you could turn things around. I've not tried coding on the Atari, but I'd imagine it's not a dissimilar experience.

Yes that is true, I think you are right. The Atari system I emulated was the same they used in the inhouse Atari development machines - with the corvus hard disk its very fast. It is like using a modern IDE in terms of speed of use. you can bounce back to and from the editor, to the assembler to the debugger, run the code on the machine. Productivity wise its much faster than using a cross-assembler. But then again. Very few Atari users would have had access to that kind of setup. It would have been a developers system. On a standard Atari it would have been pretty slow even using the floppy disks. Still its way faster than having to use a cassette tape.

I was surprised how well winApe runs in wine. I figured it would be a pain to use but its very well done. I kept thinking, where is the catch? Like i mentioned in that tutorial thread I think the biggest hindrance to CPC stuff now is the lack of source material. Hardly any of the books seem to be scanned/available. You got cpc wiki but its nowhere near the level of access to material that you have with Commodore/Atari/Spectrum books.

[Seven.FFF]

I dunno what to do about the menus. Last time I discussed it with Simon he said had been open to making a native Linux version but there was no need because it behaved perfectly under wine when he tried. I’ve never personally tried because Linux annoys me

At the very least you need to tell the emulator what machine to emulate (with zeusemulate “48K” although you can set it in the combobox) and where to start executing (ZeusPC=nnnnn, or END nnnnn for pasmo source compatibility). If there’s neither, it will just run the code in the ROM like the hardware would.

If it is cycling through different values of hl, I would guess you haven’t put a breakpoint before it returns, and it is running the IM 1 interrupt handler in the speccy rom. That polls the keyboard and does other OS stuff every frame. When running freely without a breakpoint, Zeus snapshots the registers every second or so, so it’s normal to see them changing as the program (in this case the rom interrupt handler) executes.

[Nomad]

Yea that is me being a potato and not telling zeus what target I want.

I had wondered why there is not a default target. But that is fair enough that is a design decision.

take your point about the linux, lol some days I hate it too. (Like when the update broke my system a few times. )

I am sure that in some linux distro zeus must work fine but its not just myself a number of people (well one other) mentioned the visual aids problem with the menus

With stuff like that (especially with arch) its hard to know if its the application, wine or the version of the distro that is the cause of the problem. Lol its just a roll of a dice so I hesitate to say that its a zeus issue. But its so random that stuff like the spectrumpaint fails in equally epic fashion, where as sevenup works great Same goes for winApe and Alltura (however you spell it). They ran fine out of the box.