pasmo weirdness

[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.