The point is, without a second machine to develop on, using an assembler to produce a game presents problems in itself - first the assembler takes up memory, then the text version of the code takes up more memory, and finally you have to re-load the assembler if anything crashes, compared to re-typing a few lines for a HEX loader.
Yep, that's what put me off doing anything serious in Z80 back in my teenage years, after I'd bought the assembler and then found out what a faff it would still be to get anything done. Especially after I'd played with the Plus/4 with its built-in monitor and rudimentary assembler (and soft reset).
Sometimes I still encode graphics by hand. But only for the occasional tile change when it would be quite a bit of effort to re-process everything through ZX Paintbrush just for the sake of a couple of dozen calculations I can do in my head.
without a second machine to develop on, using an assembler to produce a game presents problems in itself
True, but that's only when writing the code, not runtime. Nothing that says you can't write 5K assembly and assemble it, reset the machine, load generated code, and hand-poke a few bytes for testing / bughunting purposes.
And there's modularity: code / debug one part of the program, code / debug some other part, etc, and only put together everything when you have many tested & working building blocks.
Referring to that other thread: you know you're getting old when you know Z80 machine codes by heart (check - I'm getting old :lol: ).
Plus disassembling with SPDE and having a 9 lpi printed listing on continuous paper...
Good point - always check the actual code, no matter how it was produced. When hand-coding it's easy to make mistakes, and assemblers can have bugs too (of course, some assemblers are better than others). Or the use of some pseudo-op isn't 100% clear, and looking at the generated code makes it clear how things work.
I used O.C.P assembler back in the 80s but it had a limit on the amount of code output... a 3K bin file was usually enough source code to fill memory. I used to pre assemble code to a static location and EQU the addresses of routines. It was a complete pain in the ass and held me back in many cases. I hacked the O.C.P software to dump it's binary output to the screen so I could save it to disk using my Multiface 3 ... I would then use the snapshop option (which would often crash) to save the source code to disk...
Once I was introduced to P.D.S (Programmer's Development System) there was no going back!!!!!!!!!!!!! I was then able to write massive projects. I was always fascinated by Raffaele Cecco's use of cross development but it would be some time before I would get my hands on a real system :(
Emulators are ok and I have used them mostly for GameBoy as flashing roms takes time but I prefer a real Speccy connected to a PC!
The point to all this was that I learn't the simple (yet hard way) to code and that will stay with me forever......... it was fun and a challenge!
I did write Z-80 on paper when I went to bed as I had a curfew with the computer once 11pm had been reached... I was 14 years old but eventually I would stay on the Speccy all night and well into the next day coding ;)
I find that some people prefer emulators to real Spectrums but I can understand as it is a easy option and of course, programmers usually seek the easiest productive method for the job. I do admit that I have the ability to download games in under 10 seconds but I do like playing bombjack on the Windows build of ZX32 emu :)
The magazines really helped back in the 80s as they explained professional methods and you were likely to read those chapters because you only had an handful of magazines to last the whole month :p
I've just come across this thread and the OP has raised some very interesting points.
He wanted to know what others views and approach is....
For me, I started coding machine code in about 1986 and at the time everything I did was hand written, hand compiled and hand typed in, just as the OP is doing.
I'm quite familar with with a lot of the op codes (I could real off about 40 op codes if I need to). I also still do a lot of debugging by looking at the actual code in a (emulator debugger). The Paddy Coleman thread that R-Tape raised, I actually posted on because I could see errors in his hand compilation by sight (the forward jump, the high byte first error etc.)
However... The world of machine code really opened up when I got my first and only assembler (Currah uSource). It allowed me to code without having to worry about the tedius recoding of JR, JP and CALL addresses and offsets so I could concentrate on the actual job at hand. I don't think assembler programming itself makes you lose anything - the same view as many of the other posters. I do think that a long introduction to hand compiling using a Z80 Reference like the one at the back of the Spectrum Manual gave me a good foundation however.
Today, even a $20 android PC is too powerful to bother.... ... sigh.....
I stopped *obsessively* optimizing assembler when CPU's hit the 800mhz mark and came equipped with multiple ALUs lolz. I tend to write pipelined code and because I started with Z-80, I evolved naturally to the x86 platform...
It is very rare that I take time to streamline a routine on the PC ... it's pointless... I've not coded for ages and haven't even bothered to test the power of the new i3 CPUs ... (I use Virtual DJ to playback 720p MP4 videos with audio processing set to max on a Celeron G555 i3 and Windows 7 shows about 5% peek performance). I found the Core 2 Duo 1600mhz (T2050) to be a beast several years ago!!!
When I write PC code, I use an old platform - a Windows 98 (the last proper MS-DOS O.S. IMO) system with a AMD Duron 1600mhz (Single core) and DDR1 (PC-3200) ... The reason being is because I feel the new breed of CPU is really there to cope with the abysmal performance of modern languages and virus protection as well as over complex games/applications (not necessarily a bad thing) blah blah blah....
I write many command line applications and they usually finish their tasks before I have even taken my finger fully off the enter key lolz. A quick flick back into the text editor and the results of the next code change/tweak are seen within seconds :D It might be hard to explain to modern coders but I don't need the power of today's machines as writing pure code directly for a CPU takes complete advantage of its true performance. If I make the base spec too high then what happens when I want to port my application to a lower powered system such as a phone or the RASPBERRY PI for example... The faster the CPU, the more you can cheat and cut corners to achieve the results needed in the timescale given and I probably would these days as I am getting old lolz :D
Maybe a bit off topic here but for me, it all started with the Z-80 and machine code and now after 30+ years of the Spectrum... the same principles still apply to modern systems. A Duron @ 1600mhz * 3 ALUs with its theoretical 4,800,000,000 intructions per second is immense when compared to a Z-80 @ 3.5469 and because I used to write in pure machine code when I was a teenager, I appreciate and understand this to the max!!!!!!!!!!!!!!!
Now that most of us are older, we value our time more and have more important things to spend it on, wives, kids, jobs, houses etc.... It's up to the coder to choose the method he/she uses to control the CPU!!! type in hex, type in C++, even use HTML ... at the end of the day.... be creative, use your time wisely and don't forget to have fun doing it!!!
There is a thrill when typing in a small routine in opticode, or getting that buggy assembly routine to finally be optimized and compiled in compiler or even expressing a logic heavy function in C/C++ (and then bringing it down to asm)... like runtime polymorphism... oh how I like that!
programming is a joy and its one there is just not enough hours in the day!
I used Zeus assembler back in the 80s. I wasn't writing enough code to need a lot of memory, but the risk of crashing the machine and having to re-load everything made me very slow and cautious in coding. In later years we got a Wafadrive and transferred Zeus onto it, which made the process a bit more bearable.
My thinking was I could write the necessary code for a game in a small chunk of assembly, save it out, then use the rest of the memory for storage of scenery, sprites and enemy paths, which I could prepare in chunks with separate editors I wrote for myself in BASIC. But it never amounted to much.
I got a bit further on the ST, using the disk drive, but again it was only very late in its day that I got anywhere with writing stand-alone machine code programs, having been a bit spoiled from the off by STOS.
Using a PC IDE and emulator now skips all that Speccy faff, and I wouldn't have the time or patience to develop a game any other way.
Kudos to the machine coders..! If anyone is producing things now without an assembler then fair play to them. I wouldn't stand a chance..
The only thing I seem to be able to do quickly by memory is entering graphics - give me the 8 bits in a line and I can calculate the byte value fairly quickly. So I'm quite happy with graph paper or some other visual grid for entering graphics.
I used to hand code on the speccy back in the 80s, using DATA statements - decimal numbers though, not hex. I had a stub of basic that I knew off by heart that I used to read the data in, it allowed code relocation, by reading a variable at the start, called ST (for STart address), and I would then do stuff like DATA 33, N, ST+1000 (LD HL, ST+1000). N was assigned by a LET statement before anything was read, so I could use it in the DATA values. Of course, the BASIC had to be capable of checking for N in the values read, and act accordingly, by reading the next value and poking it into memory as a 16-bit number.
By similar methods I was also able to include text in the data values (DATA T, "blah"), change the current address etc. By the end of my speccy days, I'd even managed to include labels. Strangely, I never saved this BASIC out on its own, only with the DATA statements. I'd type it all anew each time I started a new project.
Maybe you could go into more detail on that comment ;)
I have seen in this forum a few developers posting that they don't think cross development is valid, or using a compiler, or using an assembler, or using a routine developed by someone else, or using any tool they didn't write themselves, or even using ROM calls in their code.
It would take me ages to locate these posts, but I bet many people here will remember some of these.
However many software houses in the 80's used these methods and several classic games were implemented exactly this way!
I have seen in this forum a few developers posting that they don't think cross development is valid, or using a compiler, or using an assembler, or using a routine developed by someone else, or using any tool they didn't write themselves, or even using ROM calls in their code
Yes, well, whether they think that or not, it doesn't mean we have to agree with them :)
I wasn't writing enough code to need a lot of memory, but the risk of crashing the machine and having to re-load everything made me very slow and cautious in coding. In later years we got a Wafadrive and transferred Zeus onto it, which made the process a bit more bearable.
OOC, what were you doing in the 80's writing assembly code? And who is "we"?
OOC, what were you doing in the 80's writing assembly code? And who is "we"?
Trying to make pretty colours and write a shoot-em-up with awful flickery interrupt-driven sprites. I was barely in my teens. 'We' is the family, though mostly my elder brother and I.
I have seen in this forum a few developers posting that they don't think cross development is valid, or using a compiler, or using an assembler, or using a routine developed by someone else, or using any tool they didn't write themselves, or even using ROM calls in their code.
It would take me ages to locate these posts, but I bet many people here will remember some of these.
However many software houses in the 80's used these methods and several classic games were implemented exactly this way!
So, for the real coders, hexadecimal representation is cheating, they must program in binary! :grin:
Serious now, I have not expected this topic could go so far...
Cross development for many years has been the professional way to develop for consoles and hardware that is incapable of safely hosting a disk based build and test environment (Windows, Linux, Mac, Amiga etc). Memory protection really helps when your application/game suddenly fails. Emulators have also been used for many years as they are a cheap and convenient alternative.
Developers have always found ways to link two systems together even if it means creating a crude bodge. I have even linked PC to PC for cross development with the build cycle being seconds. In the Amiga & Megadrive days, interrupts were used to detect activity on the comms ports allowing your software to automatically jump to its download routine and receive the next update then execute it!!! This also allowed you to single step trace your program to debug it!!! It saves so much time being able to do this from one press of a button on your PC :). This is also why emulators get the thumbs up from me!!!
Software houses were able to kick out games in a matter of weeks, not months.. they would also reuse game engines and share routines and libraries. It was productive and payed for development of the next project. Once duplication is booked and marketing arranged, it becomes problematic to change so that is why we have deadlines. Platform ports were ten a penny and they have a quick turn around because all versions need to be released at the same time although the 8 bit vs 16 bit market was allowed a delay. Graphic artists and team members may have also been booked for other projects so it's not a good start if your new project is delayed because the final deadline will probably stay static!!! A specific budget will have also been set and if it overruns there is less profit to sustain the company. No time to mess around!!!!!!!!!!!!!!!!!
Bedroom coders start well but working in the industry separates the time wasters and wannabees from the real true creative, adaptive and mentally focused people!!! There is no harm using professional methods when just developing for a hobby.
P.S. You may be quizzed on your ability to deal with machine code during your job interview ;)
P.S. You may be quizzed on your ability to deal with machine code during your job interview ;)
And anyone who eschews compilers and shared libraries in favour of reinventing every wheel will have their application tossed into the "no chance" pile ;)
There is no harm using professional methods when just developing for a hobby.
Unless it is your hobby to follow you own whims and fancies. Which in fact is my hobby, sorry.
When indeed a certain approach needs to be promoted among hobbyists, then I would be in favor of a scientific attitude and not the economical one.
I have a self-made printed out (dot matrix) table of alphabeticaly sorted Z80 opcodes and the decimal values, and I poked them in BASIC to enter Assembly subroutines. Never ever used a dedicated Assembler.
Nowdays I use Inline Assembler from ZXBC.
Just for the record, I have nothing against a developer that prefers to implement their own assembler, editor, libraries, etc. I know it's lots of fun to reinvent wheels, so if someone prefers to do it, that's perfectly fine.
It's only when someone posts that developers are "supposed" to reinvent everything, or that they feel developers cannot consider it's "really their code" anymore if they use someone else's library... that's the part I disagree.
I have just implemented a new Spectrum game using BIFROST*, ZX7, RCS, Rotatrix, and Fontrix. These are all tools I developed myself, in each case because I saw an opportunity to either improve on existing ideas, or implement something new. And most of all, because it was fun. None of them were implemented because I thought I "had" to do it. If I didn't have my own compressor already, I would simply have used MegaLZ in this game without thinking twice about it. Similarly I have experience implementing assemblers and compilers, but I was happy using Boriel's ZX BASIC for this project and I see no reason to ever try to reinvent it.
For me it's really simple, if it doesn't perfectly suit my task, I write it myself. If I think I can do it better, I write it myself. Sometimes I'll start off with something that seems perfectly suited and then later on realise it's not, and replace it with my own.
If it's complicated and outside my area of expertise, or requires maintenance that I haven't got the time for, and someone else has done it already, I use theirs if the license allows.
I used MegaLZ for my Microdrive snapshot conversion software, because beyond basic run length encoding, it's really not something I know much about, and the time required to learn it is not time I wish to spend!
I don't code on speccy , but 2 tools that made / helped me learn were the expert and action replay cart. I guess it wasn't really the same for speccy owners.. there is the multface which is "ok" but well..
in the AR , you could also change the numbers in the monitor by just typing in the hex
the cart made coding stuff FAR more accessible.. obv. a proper assembler (like turbo assembler etc) with labels etc.. was good
e.g on my action replay 6 on c64.. in the monitor
10000 bd 00 d8 LDA $D800,X
if I wanted to change it to say STA and knew the code for STA , I'd just go over the BD change it to 9D
I wish there was something that capable for the speccy tbh. as it was pretty much a swiss army knife for 64 owners.
...
P.S. You may be quizzed on your ability to deal with machine code during your job interview ;)
Its funny you should say that, the strangest question I have ever had was if I knew AS400 (system 36) Assembly - lucky for me my previous job was CL programming the AS400 using RGP Level 3 and C/C++ (mainly C) - to get the most use out of the system I sat there for nearly two weeks just reading the ASM document provided by IBM - found a very strange command that moves 144bytes (yes bytes) of Data.... I doubt thats ever been used - it has a massively instruction set for its time...
I did actually lean quite a bit about ASM on the early PPC processors Cobra I believe IBM called them - this was back in '96 - my Amiga had an 060@50 in them days - that was nice..... aww.... getting misty eyed now.
Anyway, fortunately I was armed with current knowledge for the interview - even if it was for an automation process for an agricultural company. Sadly while I was offered and I had taken the job, I left for another simply because their design brief for the system kept - scope creeping / changing - thus after 3 months (with no Assembly required) I left since nothing was getting done and in that business there so much entrenched management against automation that, it had taken then a further four years to get a move on the project they hired me for.. crazy eh?
There seems to be a bit of evolution going on from the original question.. But that's a good thing in my book. To share TK90XFan's opinion - I also thought this topic would not last this long. :smile:
For the record, I haven't actually sat and coded a whole game (for example) in one fell swoop, in hex. As has been mentioned earlier by another poster I tend to write small blocks of code and then build them up into a full program. This also means I get loads of reusable code blocks, nicely filed and referenced in my spreadsheet. So, things like the screen copy routine I use is always used, along with the key-press checker and sprite-writer code. As ASM mentioned earlier, if you enjoy it, keep doing it :D
I was interested to see comments about cross-development. Certainly for professional or commercial use this is the way to go. The benefits are too many to list, and, if it puts food on the table, you can't get too precious about whether it is the 'soul' or 'spirit' of coding. It's a means to an end, but still has its own charm and enjoyment factors.
As for me, well, it was mentioned m-a-n-y posts ago that coding was done on a single Speccy because that's all the user had - like many bedroom coders. This, I think really defines why I enjoy hex-bashing - it reminds me of my teenage years, sat in front of my old Hitachi 12" B&W portable TV trying to get the screen to fill faster than my mates.
Finally, I tend to mainly use Fuse on my mac, but when I get a program fully working, then it's straight into a real Speccy. Can't beat running stuff on the original hardware ;)
Comments
Yep, that's what put me off doing anything serious in Z80 back in my teenage years, after I'd bought the assembler and then found out what a faff it would still be to get anything done. Especially after I'd played with the Plus/4 with its built-in monitor and rudimentary assembler (and soft reset).
Sometimes I still encode graphics by hand. But only for the occasional tile change when it would be quite a bit of effort to re-process everything through ZX Paintbrush just for the sake of a couple of dozen calculations I can do in my head.
in my 1K games.
Just tonight I used a CP n to skip a XOR A in the latest version of "Hunt the Wumpus" for the ZX81.
setval LD A,3 DEFB 254 ; CP n entry2 XOR A INC A LD (setval+1),Aor
myprint AND 55 LD B,8 print LD A,(DE) JR C,set XOR (HL) set LD (HL),A INC H INC DE DJNZ print RETwith a call to PRINT or PRINT+1 to print OVER with the use of SCF
Other opcodes I use to hide commands are DEFB 33 (hide 2 values in HL) or JP <condition> when no register available.
I can skip some small commands without a JR, thus saving bytes!!
Don't worry yourself, it's easy to make a mistake when composing a post!!!
JUST REMEMBER TO HAVE FUN!!! IF YOU ENJOY IT THEN KEEP DOING WHAT YOU DO!!!
And there's modularity: code / debug one part of the program, code / debug some other part, etc, and only put together everything when you have many tested & working building blocks.
Referring to that other thread: you know you're getting old when you know Z80 machine codes by heart (check - I'm getting old :lol: ).
Good point - always check the actual code, no matter how it was produced. When hand-coding it's easy to make mistakes, and assemblers can have bugs too (of course, some assemblers are better than others). Or the use of some pseudo-op isn't 100% clear, and looking at the generated code makes it clear how things work.
Once I was introduced to P.D.S (Programmer's Development System) there was no going back!!!!!!!!!!!!! I was then able to write massive projects. I was always fascinated by Raffaele Cecco's use of cross development but it would be some time before I would get my hands on a real system :(
Emulators are ok and I have used them mostly for GameBoy as flashing roms takes time but I prefer a real Speccy connected to a PC!
The point to all this was that I learn't the simple (yet hard way) to code and that will stay with me forever......... it was fun and a challenge!
I did write Z-80 on paper when I went to bed as I had a curfew with the computer once 11pm had been reached... I was 14 years old but eventually I would stay on the Speccy all night and well into the next day coding ;)
Me too. At the time, I remember thinking that was obviously "the right way to do it".
Nowadays it's the opposite. Everybody can have something equivalent, but some people think they shouldn't!
The magazines really helped back in the 80s as they explained professional methods and you were likely to read those chapters because you only had an handful of magazines to last the whole month :p
Maybe you could go into more detail on that comment ;)
He wanted to know what others views and approach is....
For me, I started coding machine code in about 1986 and at the time everything I did was hand written, hand compiled and hand typed in, just as the OP is doing.
I'm quite familar with with a lot of the op codes (I could real off about 40 op codes if I need to). I also still do a lot of debugging by looking at the actual code in a (emulator debugger). The Paddy Coleman thread that R-Tape raised, I actually posted on because I could see errors in his hand compilation by sight (the forward jump, the high byte first error etc.)
However... The world of machine code really opened up when I got my first and only assembler (Currah uSource). It allowed me to code without having to worry about the tedius recoding of JR, JP and CALL addresses and offsets so I could concentrate on the actual job at hand. I don't think assembler programming itself makes you lose anything - the same view as many of the other posters. I do think that a long introduction to hand compiling using a Z80 Reference like the one at the back of the Spectrum Manual gave me a good foundation however.
Bear in mind everyone that Dr BEEP is an extreme programmer!
He programs Spectri whilst in free fall during parachute jumps! :grin:
Yeah!!! it took me a couple of nanoseconds to work out what he was doing there lolz (Ignore me tonight, I'm wired from 4K of amps blasting Avicii):
https://www.youtube.com/watch?v=bek1y2uiQGA
I stopped *obsessively* optimizing assembler when CPU's hit the 800mhz mark and came equipped with multiple ALUs lolz. I tend to write pipelined code and because I started with Z-80, I evolved naturally to the x86 platform...
It is very rare that I take time to streamline a routine on the PC ... it's pointless... I've not coded for ages and haven't even bothered to test the power of the new i3 CPUs ... (I use Virtual DJ to playback 720p MP4 videos with audio processing set to max on a Celeron G555 i3 and Windows 7 shows about 5% peek performance). I found the Core 2 Duo 1600mhz (T2050) to be a beast several years ago!!!
When I write PC code, I use an old platform - a Windows 98 (the last proper MS-DOS O.S. IMO) system with a AMD Duron 1600mhz (Single core) and DDR1 (PC-3200) ... The reason being is because I feel the new breed of CPU is really there to cope with the abysmal performance of modern languages and virus protection as well as over complex games/applications (not necessarily a bad thing) blah blah blah....
I write many command line applications and they usually finish their tasks before I have even taken my finger fully off the enter key lolz. A quick flick back into the text editor and the results of the next code change/tweak are seen within seconds :D It might be hard to explain to modern coders but I don't need the power of today's machines as writing pure code directly for a CPU takes complete advantage of its true performance. If I make the base spec too high then what happens when I want to port my application to a lower powered system such as a phone or the RASPBERRY PI for example... The faster the CPU, the more you can cheat and cut corners to achieve the results needed in the timescale given and I probably would these days as I am getting old lolz :D
Maybe a bit off topic here but for me, it all started with the Z-80 and machine code and now after 30+ years of the Spectrum... the same principles still apply to modern systems. A Duron @ 1600mhz * 3 ALUs with its theoretical 4,800,000,000 intructions per second is immense when compared to a Z-80 @ 3.5469 and because I used to write in pure machine code when I was a teenager, I appreciate and understand this to the max!!!!!!!!!!!!!!!
Now that most of us are older, we value our time more and have more important things to spend it on, wives, kids, jobs, houses etc.... It's up to the coder to choose the method he/she uses to control the CPU!!! type in hex, type in C++, even use HTML ... at the end of the day.... be creative, use your time wisely and don't forget to have fun doing it!!!
+1!
There is a thrill when typing in a small routine in opticode, or getting that buggy assembly routine to finally be optimized and compiled in compiler or even expressing a logic heavy function in C/C++ (and then bringing it down to asm)... like runtime polymorphism... oh how I like that!
programming is a joy and its one there is just not enough hours in the day!
Why yes =) you can also visit my other haunts
www.amibay.comk
www.cpcwiki.eu/forum
To name but a few ;)
I love the Amiga, but I lost my soul to the Spectrum long before... a man of two ladies if you will ;)
My thinking was I could write the necessary code for a game in a small chunk of assembly, save it out, then use the rest of the memory for storage of scenery, sprites and enemy paths, which I could prepare in chunks with separate editors I wrote for myself in BASIC. But it never amounted to much.
I got a bit further on the ST, using the disk drive, but again it was only very late in its day that I got anywhere with writing stand-alone machine code programs, having been a bit spoiled from the off by STOS.
Using a PC IDE and emulator now skips all that Speccy faff, and I wouldn't have the time or patience to develop a game any other way.
- IONIAN-GAMES.com -
The only thing I seem to be able to do quickly by memory is entering graphics - give me the 8 bits in a line and I can calculate the byte value fairly quickly. So I'm quite happy with graph paper or some other visual grid for entering graphics.
By similar methods I was also able to include text in the data values (DATA T, "blah"), change the current address etc. By the end of my speccy days, I'd even managed to include labels. Strangely, I never saved this BASIC out on its own, only with the DATA statements. I'd type it all anew each time I started a new project.
I have seen in this forum a few developers posting that they don't think cross development is valid, or using a compiler, or using an assembler, or using a routine developed by someone else, or using any tool they didn't write themselves, or even using ROM calls in their code.
It would take me ages to locate these posts, but I bet many people here will remember some of these.
However many software houses in the 80's used these methods and several classic games were implemented exactly this way!
Yes, well, whether they think that or not, it doesn't mean we have to agree with them :)
OOC, what were you doing in the 80's writing assembly code? And who is "we"?
Bytes:Chuntey - Spectrum tech blog.
- IONIAN-GAMES.com -
So, for the real coders, hexadecimal representation is cheating, they must program in binary! :grin:
Serious now, I have not expected this topic could go so far...
Developers have always found ways to link two systems together even if it means creating a crude bodge. I have even linked PC to PC for cross development with the build cycle being seconds. In the Amiga & Megadrive days, interrupts were used to detect activity on the comms ports allowing your software to automatically jump to its download routine and receive the next update then execute it!!! This also allowed you to single step trace your program to debug it!!! It saves so much time being able to do this from one press of a button on your PC :). This is also why emulators get the thumbs up from me!!!
Software houses were able to kick out games in a matter of weeks, not months.. they would also reuse game engines and share routines and libraries. It was productive and payed for development of the next project. Once duplication is booked and marketing arranged, it becomes problematic to change so that is why we have deadlines. Platform ports were ten a penny and they have a quick turn around because all versions need to be released at the same time although the 8 bit vs 16 bit market was allowed a delay. Graphic artists and team members may have also been booked for other projects so it's not a good start if your new project is delayed because the final deadline will probably stay static!!! A specific budget will have also been set and if it overruns there is less profit to sustain the company. No time to mess around!!!!!!!!!!!!!!!!!
Bedroom coders start well but working in the industry separates the time wasters and wannabees from the real true creative, adaptive and mentally focused people!!! There is no harm using professional methods when just developing for a hobby.
P.S. You may be quizzed on your ability to deal with machine code during your job interview ;)
And anyone who eschews compilers and shared libraries in favour of reinventing every wheel will have their application tossed into the "no chance" pile ;)
When indeed a certain approach needs to be promoted among hobbyists, then I would be in favor of a scientific attitude and not the economical one.
Nowdays I use Inline Assembler from ZXBC.
It's only when someone posts that developers are "supposed" to reinvent everything, or that they feel developers cannot consider it's "really their code" anymore if they use someone else's library... that's the part I disagree.
I have just implemented a new Spectrum game using BIFROST*, ZX7, RCS, Rotatrix, and Fontrix. These are all tools I developed myself, in each case because I saw an opportunity to either improve on existing ideas, or implement something new. And most of all, because it was fun. None of them were implemented because I thought I "had" to do it. If I didn't have my own compressor already, I would simply have used MegaLZ in this game without thinking twice about it. Similarly I have experience implementing assemblers and compilers, but I was happy using Boriel's ZX BASIC for this project and I see no reason to ever try to reinvent it.
If it's complicated and outside my area of expertise, or requires maintenance that I haven't got the time for, and someone else has done it already, I use theirs if the license allows.
I used MegaLZ for my Microdrive snapshot conversion software, because beyond basic run length encoding, it's really not something I know much about, and the time required to learn it is not time I wish to spend!
in the AR , you could also change the numbers in the monitor by just typing in the hex
the cart made coding stuff FAR more accessible.. obv. a proper assembler (like turbo assembler etc) with labels etc.. was good
e.g on my action replay 6 on c64.. in the monitor
10000 bd 00 d8 LDA $D800,X
if I wanted to change it to say STA and knew the code for STA , I'd just go over the BD change it to 9D
I wish there was something that capable for the speccy tbh. as it was pretty much a swiss army knife for 64 owners.
Its funny you should say that, the strangest question I have ever had was if I knew AS400 (system 36) Assembly - lucky for me my previous job was CL programming the AS400 using RGP Level 3 and C/C++ (mainly C) - to get the most use out of the system I sat there for nearly two weeks just reading the ASM document provided by IBM - found a very strange command that moves 144bytes (yes bytes) of Data.... I doubt thats ever been used - it has a massively instruction set for its time...
I did actually lean quite a bit about ASM on the early PPC processors Cobra I believe IBM called them - this was back in '96 - my Amiga had an 060@50 in them days - that was nice..... aww.... getting misty eyed now.
Anyway, fortunately I was armed with current knowledge for the interview - even if it was for an automation process for an agricultural company. Sadly while I was offered and I had taken the job, I left for another simply because their design brief for the system kept - scope creeping / changing - thus after 3 months (with no Assembly required) I left since nothing was getting done and in that business there so much entrenched management against automation that, it had taken then a further four years to get a move on the project they hired me for.. crazy eh?
For the record, I haven't actually sat and coded a whole game (for example) in one fell swoop, in hex. As has been mentioned earlier by another poster I tend to write small blocks of code and then build them up into a full program. This also means I get loads of reusable code blocks, nicely filed and referenced in my spreadsheet. So, things like the screen copy routine I use is always used, along with the key-press checker and sprite-writer code. As ASM mentioned earlier, if you enjoy it, keep doing it :D
I was interested to see comments about cross-development. Certainly for professional or commercial use this is the way to go. The benefits are too many to list, and, if it puts food on the table, you can't get too precious about whether it is the 'soul' or 'spirit' of coding. It's a means to an end, but still has its own charm and enjoyment factors.
As for me, well, it was mentioned m-a-n-y posts ago that coding was done on a single Speccy because that's all the user had - like many bedroom coders. This, I think really defines why I enjoy hex-bashing - it reminds me of my teenage years, sat in front of my old Hitachi 12" B&W portable TV trying to get the screen to fill faster than my mates.
Finally, I tend to mainly use Fuse on my mac, but when I get a program fully working, then it's straight into a real Speccy. Can't beat running stuff on the original hardware ;)