Programming with c#

[Wrathchild]

Some parallels in whats being attempted here with something that was done for Palm Pilots with the Jump project where Java byte-code was re-worked into 68000 assembly code which could then be assembled into an executable (linked with resources) so that this would then run natively on the device with no need for a VM. Always felt this could have been nice to build programs for the ST.

[UNIXcoffee928]

You keep the case ON to keep the computer cool, you keep the case OFF to heat the house.

 

= )

 

 

See attachment.

[MasterI]

You keep the case ON to keep the computer cool, you keep the case OFF to heat the house.

= )

See attachment.

 

Cool attachment! But not applicable here. System is the house, not the computer.

 

If the case is ON the computer is cool, but only because the heat has been transported in my house.

My Computer has 3 fans to cool it. If the Case is OFF (open) they run slow, because the air temperatur is nearly the temperatur of my house.

If the case is closed they run fast, because it is getting hot in the closed case.

So a close case will heat the house more because of the extra electrical energy (of the fans) that is converted to thermal energy. -> The warm air of the computer is always getting outside the case to heat my house.

 

The system that gets more energy is my house and the energy comes from outside the system (via plug) as electrical energy.

 

BTW: Think of the famous fridge example: Use it opened it to get the house warm, because the compressor is on forever and it´s electrical power is converted to thermal energy.

[MasterI]

Some parallels in whats being attempted here with something that was done for Palm Pilots with the Jump project where Java byte-code was re-worked into 68000 assembly code which could then be assembled into an executable (linked with resources) so that this would then run natively on the device with no need for a VM. Always felt this could have been nice to build programs for the ST.

 

I expected that in a way. It is an easy principle. I also have done the linking with native 6502 code libraries. Mainly Joystick and Graphics 0 by now, but it works fine.

And I have the libs written on the PC too, because of the game testing. But that will not easy be possible for complex games.

I just read quit a lot about optimizing code. That is an interesting playfield ... Even the Mono Jit-Compiler is going to change to new Methods ...

 

If I had a traceable ATARI XL-Emulator with 6502 breakpoint-debugger it would be easier to find bugs in the generated code.

[cas]

If I had a traceable ATARI XL-Emulator with 6502 breakpoint-debugger it would be easier to find bugs in the generated code.

 

Atari800MacOSX has a trace debugger with breakpoints. Might be a good reason to buy a Mac

 

The Atari800MacOSX is the best Emulator for Programmers (IMHO)

 

CONT						   - Continue emulation
SHOW						   - Show registers
STACK						  - Show stack
SET{PC,A,S,X,Y} hexval		 - Set register value
SET{N,V,D,I,Z,C}			   - Set flag value
CLR{N,V,D,I,Z,C}			   - Clear flag value
C startaddr hexval...		  - Change memory
D [startaddr]				  - Disassemble memory
F startaddr endaddr hexval	 - Fill memory
M [startaddr]				  - Memory list
MM srcaddr destaddr bytecnt	- Move Memory
S startaddr endaddr hexval...  - Search memory
ROM startaddr endaddr		  - Convert memory block into ROM
RAM startaddr endaddr		  - Convert memory block into RAM
HARDWARE startaddr endaddr	 - Convert memory block into HARDWARE
BANK [banknum]				 - Switch memory bank (XE systems)
READ file startaddr nbytes	 - Read file into memory
READSEC drive# sector count addr - Read disk sectors into memory
WRITE startaddr endaddr [file] [init>0] [run>0]
						   - Write memory block to a file (memdump.dat)
WRITESEC drive# sector count addr  - Write disk sectors from memory
SUM startaddr endaddr		  - SUM of specified memory range
TRON file					  - Trace on
TROFF						  - Trace off
BREAK [addr]				   - Set breakpoint at address
YBREAK [pos], or [1000+pos]	- Break at scanline or flash scanline
BRKHERE [on|off]			   - Set BRK opcode behaviour
MONHIST [on|off]			   - Turn monitor history keeping on/off
HISTORY or H				   - Disasm. last 32 PC addrs. 
JUMPS						  - List last 32 locations of JMP/JSR
G							  - Execute 1 instruction
O							  - Step over the instruction
R							  - Execute until return
B							  - Breakpoint (B ? for help)
A [startaddr]				  - Start simple assembler
ANTIC, GTIA, PIA, POKEY		- Display hardware registers
DLIST [startaddr]			  - Show Display List
DLIST CURR					 - Show Current Display List
LABELS file					- Load labels from file (xasm format)
COLDSTART, WARMSTART		   - Perform system coldstart/warmstart
QUIT						   - Quit emulator

Carsten

Edited September 25, 2008 by cas

[Urchlay]

Atari800MacOSX has a trace debugger with breakpoints. Might be a good reason to buy a Mac

 

The Atari800MacOSX is the best Emulator for Programmers (IMHO)

 

Plain Atari800 and Atari800WinPlus have the same thing. No need to buy a new machine... The OSX and WinPlus versions have OSX and Windows style user interfaces, but the emulation engine and debugger are the same as the original Atari800.

[cas]

Atari800MacOSX has a trace debugger with breakpoints. Might be a good reason to buy a Mac

 

The Atari800MacOSX is the best Emulator for Programmers (IMHO)

 

Plain Atari800 and Atari800WinPlus have the same thing. No need to buy a new machine... The OSX and WinPlus versions have OSX and Windows style user interfaces, but the emulation engine and debugger are the same as the original Atari800.

 

I'm not 100% sure, but I think Marc Grebe has extended the Atari800 Emulator on MacOS X in many ways over the 'normal' Atari800, especially when it comes to Debugging. Also, it has some more emulated hardware, like XEP80 Emulation, which is not in the normal Atari800.

 

I might be wrong here, at least the Linux Version 2.0.3 of Atari800 does not have all the features that the MacOS X version has.

 

Carsten

[Urchlay]

I'm not 100% sure, but I think Marc Grebe has extended the Atari800 Emulator on MacOS X in many ways over the 'normal' Atari800, especially when it comes to Debugging. Also, it has some more emulated hardware, like XEP80 Emulation, which is not in the normal Atari800.

 

I might be wrong here, at least the Linux Version 2.0.3 of Atari800 does not have all the features that the MacOS X version has.

 

The XEPP80 emulation is in atari800 CVS... however you're right, your list of debugger commands from OSX includes some commands not in plain atari800, even current CVS. That'd be a crazy reason for someone to spend a couple thousand on a Mac though

[+poobah]

I'm not 100% sure, but I think Marc Grebe has extended the Atari800 Emulator on MacOS X in many ways over the 'normal' Atari800, especially when it comes to Debugging. Also, it has some more emulated hardware, like XEP80 Emulation, which is not in the normal Atari800.

 

I might be wrong here, at least the Linux Version 2.0.3 of Atari800 does not have all the features that the MacOS X version has.

 

The XEPP80 emulation is in atari800 CVS... however you're right, your list of debugger commands from OSX includes some commands not in plain atari800, even current CVS. That'd be a crazy reason for someone to spend a couple thousand on a Mac though

 

Oh come on, I picked up an intel mac mini from craigslist a couple weeks ago for $300.

[cas]

I'm not 100% sure, but I think Marc Grebe has extended the Atari800 Emulator on MacOS X in many ways over the 'normal' Atari800, especially when it comes to Debugging. Also, it has some more emulated hardware, like XEP80 Emulation, which is not in the normal Atari800.

 

I might be wrong here, at least the Linux Version 2.0.3 of Atari800 does not have all the features that the MacOS X version has.

 

The XEPP80 emulation is in atari800 CVS... however you're right, your list of debugger commands from OSX includes some commands not in plain atari800, even current CVS. That'd be a crazy reason for someone to spend a couple thousand on a Mac though

 

of course you are mostly right, buying a new machine _only_ Atari800MacOS Xis an overkill.

 

It would be nice to see the new features in the MacOS X version of Atari800 to be picked up in the main source trunk, so that I can also use them on Unix.

 

Carsten

[MasterI]

I'm not 100% sure, but I think Marc Grebe has extended the Atari800 Emulator on MacOS X in many ways over the 'normal' Atari800, especially when it comes to Debugging. Also, it has some more emulated hardware, like XEP80 Emulation, which is not in the normal Atari800.

 

I might be wrong here, at least the Linux Version 2.0.3 of Atari800 does not have all the features that the MacOS X version has.

 

The XEPP80 emulation is in atari800 CVS... however you're right, your list of debugger commands from OSX includes some commands not in plain atari800, even current CVS. That'd be a crazy reason for someone to spend a couple thousand on a Mac though

 

of course you are mostly right, buying a new machine _only_ Atari800MacOS Xis an overkill.

 

It would be nice to see the new features in the MacOS X version of Atari800 to be picked up in the main source trunk, so that I can also use them on Unix.

 

Carsten

 

In Atari800 2.0.3 windx they are already working. Just press F8 (Enter Monitor). The graphics is switched off, but the program can be stepped ...

Setting Breakpoints is not easy but they are better than nothing.

 

That was a nice hint !

[cas]

In Atari800 2.0.3 windx they are already working. Just press F8 (Enter Monitor). The graphics is switched off, but the program can be stepped ...

Setting Breakpoints is not easy but they are better than nothing.

 

The Atari800 Emulator has the Monitor and Breakpoint handling for a long time, but the MacOS X version has a improved handling of that.

 

Also, when doing code-generation for 6502 CPUs, the article "A-LANG: WAYS TO IMPLEMENT COMPUTER LANGUAGES ON 6502s" by David A. Wheeler is a _must read_:

http://www.dwheeler.com/6502/a-lang.txt

Edited September 28, 2008 by cas